Multi-tenancy using shared databases

Inventor: Volker Driesen (Heidelberg, DE)

Assignee: SAP SE

G06F16/2379 G06F16/219 G06F16/27

View Patent ↗

Loading inventors, assignments & file history…

Monitor This Case

Get email alerts when status or documents change.

Order Certified Copies

Most orders are placed with the USPTO same day — all within 24 business hours.

Order via The Patent Place →

Pre-filled with this patent's details

Quick Facts

Patent No.: US 12664150
App. No.: 17/504,687
Granted: Jun 23, 2026
Kind: B2

External Links

USPTO Patent Center↗ Full Patent PDF↗

Abstract

Implementations include providing a set of tenant databases within a cloud platform, each tenant database being executed as a database instance within a respective resource unit, providing a set of shared databases within the cloud platform, each shared database being executed as a database instance within a respective resource unit, at least one shared database being accessed by two or more tenant databases of the set of tenant databases, defining, within the set of tenant databases, one or more execution groups, each execution group including two or more tenant databases of the set of tenant databases, executing, for a first execution group, an update procedure to provide a first target version shared database, the first target version shared database being updated relative to one or more source version shared databases, and switching each tenant database in the first execution group to read from the first target version shared database.

Claims (43)

1 . A computer-implemented method for providing shared databases in multi-tenancy database systems, the method comprising:

providing a set of tenant databases within a cloud platform, the set of tenant databases comprising a first tenant database and a second tenant database in a first availability zone;

providing a set of shared databases within the cloud platform, the set of shared databases comprising a first shared database in the first availability zone, the first shared database being a source version and being accessed by the first tenant database and the second tenant database in the first availability zone;

defining, within the set of tenant databases, one or more execution groups, a first execution group comprising the first tenant database and a second execution group comprising the second tenant database, the first tenant database and the second tenant database both being assigned to a first logical cluster;

executing, for the first execution group, an update procedure to provide a second shared database in a target version that is updated relative to the source version;

switching the first tenant database in the first execution group to read from the second shared database, and after the update procedure, the second tenant database still accessing the first shared database;

in response to switching the first tenant database, moving the first tenant database from the first logical cluster to a second logical cluster for execution of an operation relative to a second availability zone;

executing, for the second execution group, an update procedure to provide a third shared database; and

switching each tenant database in the second execution group to read from the third shared database.

2 . The method of claim 1 , wherein tenant databases in the set of tenant databases comprise different types of tenant databases.

3 . The method of claim 1 , further comprising defining, within the set of tenant databases, a set of logical clusters comprising the first logical cluster and the second logical cluster, tenant databases in a logical cluster reading from a same shared database, each logical cluster enabling reconfiguration in event of occurrence of a failover.

4 . The method of claim 1 , wherein, prior to the update procedure, a third tenant database in the first execution group accesses a third shared database.

5 . The method of claim 1 , wherein each shared database is mirrored in the first availability zone and the second availability zone.

6 . The method of claim 1 , wherein the cloud platform is provisioned in Kubernetes and each resource unit comprises a pod.

7 . A non-transitory computer-readable storage medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations for migration of one or more of objects and one or more workloads from a source database system to a target database system, the operations comprising:

providing a set of tenant databases within a cloud platform, the set of tenant databases comprising a first tenant database and a second tenant database in a first availability zone;

executing, for the first execution group, an update procedure to provide a second shared database in a target version that is updated relative to the source version;

executing, for the second execution group, an update procedure to provide a third shared database; and

switching each tenant database in the second execution group to read from the third shared database.

8 . The non-transitory computer-readable storage medium of claim 7 , wherein tenant databases in the set of tenant databases comprise different types of tenant databases.

9 . The non-transitory computer-readable storage medium of claim 7 , wherein operations further comprise defining, within the set of tenant databases, a set of logical clusters comprising the first logical cluster and the second logical cluster, tenant databases in a logical cluster reading from a same shared database, each logical cluster enabling reconfiguration in event of occurrence of a failover.

10 . The non-transitory computer-readable storage medium of claim 7 , wherein, prior to the update procedure, a third tenant database in the first execution group accesses a third shared database.

11 . The non-transitory computer-readable storage medium of claim 7 , wherein each shared database is mirrored in the first availability zone and the second availability zone.

12 . The non-transitory computer-readable storage medium of claim 7 , wherein the cloud platform is provisioned in Kubernetes and each resource unit comprises a pod.

13 . A system, comprising:

a computing device; and

a computer-readable storage device coupled to the computing device and having instructions stored thereon which, when executed by the computing device, cause the computing device to perform operations for migration of one or more of objects and one or more workloads from a source database system to a target database system, the operations comprising:

providing a set of tenant databases within a cloud platform, the set of tenant databases comprising a first tenant database and a second tenant database in a first availability zone;

executing, for the first execution group, an update procedure to provide a second shared database in a target version that is updated relative to the source version;

executing, for the second execution group, an update procedure to provide a third shared database; and

switching each tenant database in the second execution group to read from the third shared database.

14 . The system of claim 13 , wherein tenant databases in the set of tenant databases comprise different types of tenant databases.

15 . The system of claim 13 , wherein operations further comprise defining, within the set of tenant databases, a set of logical clusters comprising the first logical cluster and the second logical cluster, tenant databases in a logical cluster reading from a same shared database, each logical cluster enabling reconfiguration in event of occurrence of a failover.

16 . The system of claim 13 , wherein, prior to the update procedure, a third tenant database in the first execution group accesses a third shared database.

17 . The system of claim 13 , wherein each shared database is mirrored in the first availability zone and the second availability zone.