Maintaining cross-node coherence of an in-memory database object in a multi-node database cluster

Patent metadata

Field	Value
Publication number	US-10216781-B2
Application number	US-201514983496-A
Country	US
Kind code	B2
Filing date	Dec 29, 2015
Priority date	May 29, 2015
Publication date	Feb 26, 2019
Grant date	Feb 26, 2019

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.

First claim

What is claimed is:

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 one or more 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, within the first in-memory copy of the first chunk, data that is generated from the particular unit covered by the first lock is invalid;
the first database server instance responding to requests to read data from the first chunk by:
accessing the first indication;
obtaining data items, that belong to the first chunk and that are not identified as invalid by the first indication, from the first in-memory copy; and
obtaining data items, that belong to the first chunk and that are identified as invalid by the first indication, 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 data 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 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;
the second database server instance responding 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 data in the third in-memory copy of the third chunk that is also generated from the particular unit is invalid;
the third database server instance responding to requests to read data from the third chunk by:
obtaining data items, that belong to the third chunk and that have not been invalidated in the third in-memory copy, from the third in-memory copy; and
obtaining data items, that belong to the third

Assignees

• Oracle Int Corp

Inventors

• Hase Sanket
• Macnaughton Neil
• Raja Vivekanandhan
• Mullick Atrayee
• Marwah Vineet
• Ganesh Amit

Classifications

• G06F12/1466

  Key-lock mechanism · CPC title

• G06F12/0875

  with dedicated cache, e.g. instruction or stack · CPC title

• G06F2212/1024

  Latency reduction · CPC title

• G06F2212/1052

  Security improvement · CPC title

• G06F16/2365

  Ensuring data consistency and integrity · CPC title