MAINTAINING CROSS-NODE COHERENCE OF AN IN-MEMORY DATABASE OBJECT IN A MULTI-NODE DATABASE CLUSTER

• US 20160350352A1
• Filed: 12/29/2015
• Published: 12/01/2016
• Est. Priority Date: 05/29/2015
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: HASE, SANKET, MACNAUGHTON, NEIL, RAJA, VIVEKANANDHAN, MULLICK, ATRAYEE, MARWAH, VINEET, GANESH, AMIT
• Granted Patent: US 10,216,781 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 12/084 with a shared cache
• CPC Class Codes: G06F 12/0868 Data transfer between cache memory and other subsystems, e.g. storage devices or host systems
• CPC Class Codes: G06F 12/0875 with dedicated cache, e.g. instruction or stack
• CPC Class Codes: G06F 12/1466 Key-lock mechanism
• CPC Class Codes: G06F 16/2343 Locking methods, e.g. distributed locking or locking implementation details
• CPC Class Codes: G06F 16/2365 Ensuring data consistency and integrity
• CPC Class Codes: G06F 16/27 Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
• CPC Class Codes: G06F 2212/1024 Latency reduction
• CPC Class Codes: G06F 2212/1052 Security improvement
• CPC Class Codes: G06F 2212/465 Structured object, e.g. database record

Abstract

Techniques are described for maintaining coherency of a portion of a database object populated in the volatile memories of multiple nodes in a database cluster. The techniques involve maintaining a local invalidation bitmap for chunks of data stored in memory in each particular node in the cluster by tracking locks granted by a lock manager. During a pre-loading operation, each given node requests a set of shared locks associated with the chunks of data to be store in the given node'"'"'s memory. When a request to release one of these shared locks occurs, the in-memory copy of those data items may be invalidated in the node releasing its shared lock.

Claims

1. A method comprising:

maintaining, in a persistent storage, a database that is accessible to a plurality of database server instances;

wherein the database includes a table that is physically organized in a plurality of units, wherein each unit of the plurality of units is stored in persistent storage and comprises one or more contiguous rows of the table stored in row-major format;

generating, in a first volatile memory local to a first database server instance of the plurality of database server instances, a first in-memory copy of a first chunk of the table;

wherein the first in-memory copy of the first chunk of the table comprises one or more columns from one or more units of the plurality of units in column-major format;

acquiring, by the first database server instance, a first lock that covers a particular unit of the plurality of units;

receiving, at the first database server instance, a first request to release the first lock;

in response to receiving the first request, releasing the first lock, and

in response to releasing the first lock, storing, in the first volatile memory, a first indication that each row in the first in-memory copy of the first chunk that is also generated from the particular unit is invalid;

wherein the first database server instance responds to requests to read data from the first chunk by;

obtaining data items, that belong to the first chunk and that have not been invalidated in the first in-memory copy, from the first in-memory copy; and

obtaining data items, that belong to the first chunk and have been invalidated in the first in-memory copy, from a source other than the first in-memory copy;

wherein the method is performed by one or more computing devices.

2. The method of claim 1,

wherein each unit of the plurality of units is a block, wherein a given block comprises each column of two or more contiguous rows of the table stored in row-major format;

wherein the first lock covers the particular unit that is a particular block, wherein the first indication indicates that each row in the first in-memory copy of the first chunk that is also generated from the particular block is invalid.

3. The method of claim 1,

wherein each unit of the plurality of units is a row of the table stored in row-major format;

wherein the first lock covers the particular unit that is a particular row, wherein the first indication indicates that a given row in the first in-memory copy of the first chunk that is also generated from the particular row is invalid.

4. The method of claim 1, wherein the first indication is stored in a first invalidation bitmap with one or more bits of the first invalidation bitmap corresponding to a respective unit used to generate the first in-memory copy.

5. The method of claim 4, the method further comprising:

determining the first invalidation bitmap is in use;

in response to determining the first invalidation bitmap is in use, creating a temporary invalidation bitmap for storing the first indication to enable a release of the first lock without requiring storing of the first indication in the first invalidation bitmap before the release; and

performing a union between of the first invalidation bitmap and the temporary invalidation bitmap to update the first invalidation bitmap.

6. The method of claim 1, the method further comprising:

prior to the first database server instance receiving the first request to release the first lock;

generating, in a second volatile memory local to a second database server instance of the plurality of database server instances, a second in-memory copy of a second chunk of the table, wherein the first chunk and the second chunk are generated from the same one or more units of the plurality of units;

acquiring, by the second database server instance, a second lock that covers the particular unit of the plurality of units, wherein both the first lock and the second lock are shared locks;

receiving, at the second database server instance, a second request to modify a particular row of the particular unit;

requesting, by the second database server instance, an exclusive lock that covers the particular unit;

after the first database server instance receives the first request to release the first lock;

acquiring, by the second database server instance, the exclusive lock that covers the particular unit of the plurality of units;

recording, by the second database server instance, a modification to the particular row of the particular unit;

committing the modification to the particular row of the particular unit;

in response to a committing the modification, storing, in the second volatile memory, a second indication that a given row in the second in-memory copy that is also generated from the particular row is invalid;

wherein the second database server instance responds to requests to read data from the second chunk by;

obtaining data items, that belong to the second chunk and that have not been invalidated in the second in-memory copy, from the second in-memory copy; and

obtaining data items, that belong to the second chunk and have been invalidated in the second in-memory copy, from at least one source other than the second in-memory copy.

7. The method of claim 6,

wherein the first indication and the second indication indicate invalidations at different levels of granularity.

8. The method of claim 6, wherein the second database server instance additionally stores, in response to the committing of the modification, an up-to-date unit that indicates the modification, and provides the up-to-date unit to the first database server instance.

9. The method of claim 6, wherein the second in-memory copy of the second chunk of the table comprises a different one or more columns from the same one or more units of the plurality of units than the first in-memory copy of the first chunk of the table.

10. The method of claim 6, wherein the second in-memory copy of the second chunk of the table comprises the same one or more columns from the same one or more units of the plurality of units as the first in-memory copy of the first chunk of the table.

11. The method of claim 6, the method further comprising:

prior to the second database server instance receiving the second request to modify the particular row of the particular unit;

generating, in a third volatile memory local to a third database server instance of the plurality of database server instances, a third in-memory copy of a third chunk of the table, wherein the first chunk, second chunk, and the third chunk are generated from the same one or more units of the plurality of units;

acquiring, by the third database server instance, a third lock that covers the particular unit of the plurality of units, wherein both the first lock and the third lock are shared locks;

after the second database server instance receives the second request to modify the particular row of the particular unit;

receiving, at the third database server instance, a third request to release the third lock;

in response to receiving the third request, releasing the third lock, and

in response to releasing the third lock, storing, in the third volatile memory, a third indication that each row in the third in-memory copy of the third chunk that is also generated from the particular unit is invalid;

wherein the third database server instance responds to requests to read data from the first chunk by;

obtaining data items, that belong to the third chunk and that have not been invalidated in the first in-memory copy, from the first in-memory copy; and

obtaining data items, that belong to the third chunk and have been invalidated in the first in-memory copy, from a source other than the first in-memory copy.

12. One or more non-transitory computer-readable media storing instructions, wherein the instructions include:

instructions which, when executed by one or more hardware processors, cause maintaining, in a persistent storage, a database that is accessible to a plurality of database server instances;

wherein the database includes a table that is physically organized in a plurality of units, wherein each unit of the plurality of units is stored in persistent storage and comprises one or more contiguous rows of the table stored in row-major format;

instructions which, when executed by the one or more hardware processors, cause generating, in a first volatile memory local to a first database server instance of the plurality of database server instances, a first in-memory copy of a first chunk of the table;

wherein the first in-memory copy of the first chunk of the table comprises one or more columns from one or more units of the plurality of units in column-major format;

instructions which, when executed by the one or more hardware processors, cause acquiring, by the first database server instance, a first lock that covers a particular unit of the plurality of units;

instructions which, when executed by the one or more hardware processors, cause receiving, at the first database server instance, a first request to release the first lock;

instructions which, when executed by the one or more hardware processors, cause, in response to receiving the first request, releasing the first lock, and

instructions which, when executed by the one or more hardware processors, cause, in response to releasing the first lock, storing, in the first volatile memory, a first indication that each row in the first in-memory copy of the first chunk that is also generated from the particular unit is invalid;

wherein the first database server instance responds to requests to read data from the first chunk by;

obtaining data items, that belong to the first chunk and that have not been invalidated in the first in-memory copy, from the first in-memory copy; and

obtaining data items, that belong to the first chunk and have been invalidated in the first in-memory copy, from a source other than the first in-memory copy.

13. The one or more non-transitory computer-readable media of claim 12,

wherein each unit of the plurality of units is a block, wherein a given block comprises each column of two or more contiguous rows of the table stored in row-major format;

wherein the first lock covers the particular unit that is a particular block, wherein the first indication indicates that each row in the first in-memory copy of the first chunk that is also generated from the particular block is invalid.

14. The one or more non-transitory computer-readable media of claim 12,

wherein each unit of the plurality of units is a row of the table stored in row-major format;

wherein the first lock covers the particular unit that is a particular row, wherein the first indication indicates that a given row in the first in-memory copy of the first chunk that is also generated from the particular row is invalid.

15. The one or more non-transitory computer-readable media of claim 12, wherein the first indication is stored in a first invalidation bitmap with one or more bits of the first invalidation bitmap corresponding to a respective unit used to generate the first in-memory copy.

16. The one or more non-transitory computer-readable media of claim 15, wherein the instructions further include:

instructions which, when executed by the one or more hardware processors, cause determining the first invalidation bitmap is in use;

instructions which, when executed by the one or more hardware processors, cause, in response to determining the first invalidation bitmap is in use, creating a temporary invalidation bitmap for storing the first indication to enable a release of the first lock without requiring storing of the first indication in the first invalidation bitmap before the release; and

instructions which, when executed by the one or more hardware processors, cause performing a union between of the first invalidation bitmap and the temporary invalidation bitmap to update the first invalidation bitmap.

17. The one or more non-transitory computer-readable media of claim 12, wherein the instructions further include:

instructions which, when executed by the one or more hardware processors, cause, prior to the first database server instance receiving the first request to release the first lock;

generating, in a second volatile memory local to a second database server instance of the plurality of database server instances, a second in-memory copy of a second chunk of the table, wherein the first chunk and the second chunk are generated from the same one or more units of the plurality of units;

acquiring, by the second database server instance, a second lock that covers the particular unit of the plurality of units, wherein both the first lock and the second lock are shared locks;

receiving, at the second database server instance, a second request to modify a particular row of the particular unit;

requesting, by the second database server instance, an exclusive lock that covers the particular unit;

instructions which, when executed by the one or more hardware processors, cause, after the first database server instance receives the first request to release the first lock;

acquiring, by the second database server instance, the exclusive lock that covers the particular unit of the plurality of units;

recording, by the second database server instance, a modification to the particular row of the particular unit;

committing the modification to the particular row of the particular unit;

in response to committing the modification, storing, in the second volatile memory, a second indication that a given row in the second in-memory copy that is also generated from the particular row is invalid;

wherein the second database server instance responds to requests to read data from the second chunk by;

obtaining data items, that belong to the second chunk and that have not been invalidated in the second in-memory copy, from the second in-memory copy; and

obtaining data items, that belong to the second chunk and have been invalidated in the second in-memory copy, from at least one source other than the second in-memory copy.

18. The one or more non-transitory computer-readable media of claim 17, wherein the first indication and the second indication indicate invalidations at different levels of granularity.

19. The one or more non-transitory computer-readable media of claim 17, wherein the second database server instance additionally stores, in response to the committing of the modification, an up-to-date unit that indicates the modification, and provides the up-to-date unit to the first database server instance.

20. The one or more non-transitory computer-readable media of claim 17, wherein the second in-memory copy of the second chunk of the table comprises a different one or more columns from the same one or more units of the plurality of units than the first in-memory copy of the first chunk of the table.

21. The one or more non-transitory computer-readable media of claim 17, wherein the second in-memory copy of the second chunk of the table comprises the same one or more columns from the same one or more units of the plurality of units as the first in-memory copy of the first chunk of the table.

22. The one or more non-transitory computer-readable media of claim 17, wherein the instructions further include:

instructions which, when executed by the one or more hardware processors, cause, prior to the second database server instance receiving the second request to modify the particular row of the particular unit;

generating, in a third volatile memory local to a third database server instance of the plurality of database server instances, a third in-memory copy of a third chunk of the table, wherein the first chunk, second chunk, and the third chunk are generated from the same one or more units of the plurality of units;

acquiring, by the third database server instance, a third lock that covers the particular unit of the plurality of units, wherein both the first lock and the third lock are shared locks;

instructions which, when executed by the one or more hardware processors, cause, after the second database server instance receives the second request to modify the particular row of the particular unit;

receiving, at the third database server instance, a third request to release the third lock;

in response to receiving the third request, releasing the third lock, and

in response to releasing the third lock, storing, in the third volatile memory, a third indication that each row in the third in-memory copy of the third chunk that is also generated from the particular unit is invalid;

wherein the third database server instance responds to requests to read data from the first chunk by;

obtaining data items, that belong to the third chunk and that have not been invalidated in the first in-memory copy, from the first in-memory copy; and

obtaining data items, that belong to the third chunk and have been invalidated in the first in-memory copy, from a source other than the first in-memory copy.