Single-database multiple-tenant software system upgrade

• US 8,793,230 B2
• Filed: 10/23/2012
• Issued: 07/29/2014
• Est. Priority Date: 10/23/2012
• Status: Active Grant

• Current Assignee: SAP SE
• Original Assignee: SAP AG (SAP SE)
• Inventors: Engelko, Andrey, Driesen, Volker
• Primary Examiner(s): NGUYEN, CAM LINH T
• Application Number:
  US13/658,644
• Publication Number:
  US 20140114913A1
• Time in Patent Office: 644 Days
• Field of Search: 707/638, 707/695, 707/803, 707/809
• US Class Current: 707/695
• CPC Class Codes: G06F 16/119 Details of migration of file systems migration mechanisms in storage systems G06F3/0647

Abstract

Example systems and methods of upgrading a single-database, multiple-tenant software system are presented. In one example, a target database schema for a target version of the software system is created. For each tenant of a current database schema for a current version of the software system, a current state of the data corresponding to the tenant in the current database schema is captured. The data corresponding to the tenant is transitioned from the current database schema to the target database schema. The tenant in the target database schema is tested to verify the tenant. If the tenant in the target database schema is verified, the tenant in the target database schema is opened for users. If not verified, the tenant in the current database schema is restored using the captured state.

Claims

1. A method, comprising:

creating, in a database, a target database schema for a target version of a software system; and

upgrading a plurality of tenants in a current database schema of a current version of the software system to the target database schema, the upgrading comprising, for each tenant;

capturing a current state of data corresponding to the tenant in the current database schema;

transitioning, using at least one processor of a machine, the data corresponding to the tenant from the current database schema to the target database schema, the transitioning comprising transitioning a first data group of the data corresponding to the tenant in the current database schema to the target database schema while executing the tenant of the current database schema, and transitioning a second data group of the data corresponding to the tenant in the current database schema from the current database schema to the target database schema while the tenant of the current database schema is stopped;

testing to verify the tenant in the target database schema;

opening the tenant in the target database schema for users in response to the tenant in the target database schema being verified; and

restoring the tenant in the current database schema using the captured state in response to the tenant in the target database schema not being verified.

2. The method of claim 1, further comprising:

for each tenant in the current database schema, retrying the capturing of the current state, the transitioning of the data, and the testing of the tenant after the restoring of the tenant in the current database schema.

3. The method of claim 1, further comprising:

deleting the current database schema from the database in response to the plurality of tenants in the target database schema being verified.

4. The method of claim 1, the transitioning of the data corresponding to the tenant further comprising:

assigning data corresponding to the tenant in the target database schema based on the data corresponding to the tenant in the current database schema; and

adjusting at least a portion the data corresponding to the tenant in the target database schema for use in the target database schema.

5. The method of claim 1, further comprising:

locking tenant-independent data of the current database schema from changes; and

creating tenant-independent data for the target database schema based on the tenant-independent data of the current database schema after locking the tenant-independent data of the current database schema;

the locking of the tenant-independent data of the current database schema and the creating of the tenant-independent data for the target database schema occurring prior to the upgrading of any of the plurality of tenants of the current database schema.

6. The method of claim 1, the transitioning of the data corresponding to the tenant from the current database schema to the target database schema further comprising:

locking metadata of the tenant in the current database schema from changes;

copying the locked metadata to the target database schema; and

updating the copied metadata according to the target database schema.

7. The method of claim 1, the transitioning of the data corresponding to the tenant from the current database schema to the target database schema further comprising:

apportioning the data corresponding to the tenant in the current database schema to one of the first data group and the second data group prior to the transitioning of the first data group from the current database schema to the target database schema.

8. The method of claim 7, the apportioning of the data being based on an amount of processing to transition the data from the current database schema to the target database schema, the first data group requiring more processing to transition than the second data group.

9. The method of claim 7, the apportioning of the data being based on an amount of data conversion to transition the data from the current database schema to the target database schema, the first data group requiring more data conversion than the second data group.

10. The method of claim 1, the transitioning of the first data group comprising:

copying the first data group in the current database schema to the target database schema;

updating the first data group in the target database schema based on the target database schema;

recording changes made to the first data group in the current database schema after the copying of the first data group to the target database schema; and

revising the first data group in the target database schema based on the recorded changes.

11. The method of claim 1, the

transitioning of the data corresponding to the tenant from the current database schema to the target database schema further comprising:

stopping execution of the tenant of the current database schema after the transitioning of the first data group from the current database schema to the target database schema;

the capturing of the current state of the data corresponding to the tenant in the current database schema occurring after the stopping of the execution of the tenant of the current database schema and before the transitioning of the second data group from the current database schema to the target database schema.

12. The method of claim 1, the transitioning of the second data group comprising:

adjusting the second data group in the target database schema according to the target database schema.

13. The method of claim 1, the upgrading of at least two of the plurality of tenants in the current database schema occurring at different times.

14. A non-transitory computer-readable storage medium including instructions that, when executed by at least one processor of a machine, cause the machine to perform operations comprising:

creating, in a database, a target database schema for a target version of a software system; and

upgrading, to the target database schema, a plurality of tenants in a current database schema of a current version of the software system, the upgrading comprising, for each tenant;

capturing a current state of data corresponding to the tenant in the current database schema;

transitioning the data corresponding to the tenant from the current database schema to the target database schema, the transitioning comprising transitioning a first portion of the data while the tenant in the current database schema is operating and transitioning a second portion of the data while the tenant in the current database schema is stopped;

testing to verify the tenant in the target database schema;

opening the tenant in the target database schema for users in response to the tenant in the target database schema being verified; and

restoring the tenant in the current database schema using the captured state in response to the tenant in the target database schema not being verified.

15. The non-transitory computer-readable storage medium of claim 14, the current database schema comprising a separate current database schema for each of the plurality of tenants, the target database schema comprising a separate target database schema for each of the plurality of tenants.

16. The non-transitory computer-readable storage medium of claim 14, the current database schema comprising a single current database schema for all of the plurality of tenants, the target database schema comprising a single target database schema for all of the plurality of tenants, the transitioning of the data employing tenant-specific operations for each of the plurality of tenants.

17. A system, comprising:

a database;

at least one processor; and

a database management module comprising instructions that, when executed by the at least one processor, cause the at least one processor to perform operations comprising;

creating, in the database, a target database schema for a target version of a software system; and

upgrading, to the target database schema, a plurality of tenants in a current database schema of a current version of the software system, the upgrading comprising, for each tenant;

capturing a current state of data corresponding to the tenant in the current database schema;

transitioning, using at least one processor of a machine, the data corresponding to the tenant from the current database schema to the target database schema, the transitioning comprising transitioning a first data group of the data corresponding to the tenant in the current database schema to the target database schema while executing the tenant of the current database schema, and transitioning a second data group of the data corresponding to the tenant in the current database schema from the current database schema to the target database schema while the tenant of the current database schema is stopped;

testing to verify the tenant in the target database schema;

opening the tenant in the target database schema for users in response to the tenant in the target database schema being verified; and

restoring the tenant in the current database schema using the captured state in response to the tenant in the target database schema not being verified.

18. The system of claim 17, the operations further comprising:

for each tenant in the current database schema, retrying the capturing of the current state, the transitioning of the data, and the testing of the tenant after restoring the tenant in the current database schema.

19. The system of claim 17, the transitioning of the data corresponding to the tenant from the current database schema to the target database schema further comprising:

apportioning the data corresponding to the tenant in the current database schema to one of the first data group and the second data group prior to the transitioning of the first data group from the current database schema to the target database schema.

20. The system of claim 17, the transitioning of the data corresponding to the tenant from the current database schema to the target database schema further comprising:

stopping execution of the tenant of the current database schema after the transitioning of the first data group from the current database schema to the target database schema;

the capturing of the current state of the data corresponding to the tenant in the current database schema occurring after the stopping of the execution of the tenant of the current database schema and before the transitioning of the second data group from the current database schema to the target database schema.