VERSATILE IN-MEMORY DATABASE RECOVERY

• US 20120109895A1
• Filed: 10/28/2010
• Published: 05/03/2012
• Est. Priority Date: 10/28/2010
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Zwilling, Mike, Larson, Per-Ake, Diaconu, Cristian
• Granted Patent: US 10,430,298 B2
• Time in Patent Office: Days
• US Class Current: 707/648
• CPC Class Codes: G06F 11/1471 involving logging of persistent data for recovery
• CPC Class Codes: G06F 16/2308 Concurrency control transaction processing G06F9/466
• CPC Class Codes: G06F 16/2358 Change logging, detection, and notification replication G06F16/27
• CPC Class Codes: G06F 2201/80 Database-specific techniques

Abstract

The subject disclosure relates to a database recovery technique that implements various aspects of transaction logging to optimize database recovery performance. Transactions are logged logically with no reference to physical location, which enables logging to be performed via multiple independent log streams in parallel. A set of log streams can further be adjusted to conform to a local configuration of a mirror or secondary node in order to increase mirroring flexibility. Additionally, individual transactions or groups of transactions are recorded using a single log record, which contains timestamp information to enable database recovery without reference to physical checkpoint files. Further, techniques are provided herein for processing transactions without Write Ahead Logging or hardening of undo information. As further described herein, a transaction can be committed via a set of hierarchical stages, which in turn can facilitate integration of an in-memory database system with one or more external database systems.

Claims

1. A database management system, comprising:

a log manager component configured to generate one or more log records in a logical log record format relating to a transaction operating on data in at least one data store; and

wherein information relating to reversal of the transaction is discarded in response to commitment of the transaction.

2. The system according to claim 1, further comprising:

at least one persistent data store configured to store information corresponding to respective transactions; and

a component configured to prevent writing of data corresponding to one or more uncommitted transactions to the at least one persistent data store.

3. The system according to claim 1, wherein the log manager component is further configured to record a plurality of transactions operating on data in the at least one data store in the one or more log records.

4. The system according to claim 1, wherein the log manager component includes a log stream management component configured to maintain one or more log streams that are associated with respective log records.

5. The system according to claim 4, wherein the log stream management component is further configured to manage reorganization of the one or more log streams at least in part by merging at least one log stream of the one or more log streams or splitting at least one log stream of the one or more log streams.

6. The system according to claim 4, wherein the log stream management component is further configured to load a plurality of log streams in a parallel manner.

7. The system according to claim 6, wherein the log manager component is further configured to facilitate insertion of respective database rows corresponding to the plurality of log streams into an index corresponding to the at least one data store in a parallel manner.

8. The system according to claim 1, wherein the log manager component is further configured to record a begin time of the transaction and an end time of the transaction in the one or more log records and the system further comprises:

a recovery component configured to reconstruct an operating state of the at least one data store at least in part by applying transactions recorded via respective log records in an order determined based on the begin times and end times of the transactions as recorded in their respective log records.

9. The system according to claim 1, further comprising:

a recovery subsystem integration component configured to integrate respective transaction log records of the log manager component with respective log records of at least one disparate database system, thereby creating an appearance of a common log that includes the transaction log records of the log manager component and the transaction log records of the at least one disparate database system.

10. The system according to claim 1, wherein the log manager component comprises:

a checkpointing component configured to generate at least one checkpoint indicative of a state of the at least one data store without reference to respective physical locations in the at least one data store.

11. The system according to claim 10, wherein the checkpointing component is further configured to generate a set of partitioned checkpoints respectively indicative of the state of respective designated portions of the at least one data store.

12. The system according to claim 10, wherein the checkpointing component is further configured to generate at least one differential checkpoint indicative of the state of respective data in the at least one data store that has been modified since a previous checkpoint.

13. The system according to claim 10, wherein the checkpointing component is further configured to initiate checkpoint loading in parallel with loading of a log via the log manager component.

14. The system according to claim 1, further comprising:

a transaction processing component configured to commit the transaction via a physical commit in which recovery information corresponding to the transaction is persistently recorded, a logical commit in which changes to data in the at least one data store caused by the transaction are visible to other transactions within the at least one data store, and a visible commit in which a result of the transaction is made available to entities outside the at least one data store.

15. A method for maintaining a database recovery system, comprising:

receiving information relating to a transaction operating on data in at least one in-memory data store;

logging the transaction in one or more log records according to a logical log record format;

discarding reversal information relating to the transaction in response to commitment of the transaction; and

preventing writing of data corresponding to one or more uncommitted transactions to at least one corresponding persistent data store.

16. The method of claim 15, further comprising:

maintaining a plurality of log streams;

wherein the logging includes logging the transaction using a log stream selected from the plurality of log streams.

17. The method of claim 16, wherein the maintaining includes assigning respective input/output devices to the respective log streams of the plurality of log streams.

18. The method of claim 15, further comprising:

generating at least one checkpoint relating to a state of the at least one in-memory data store without reference to respective physical locations in the at least one in-memory data store.

19. A method for maintaining a database recovery system, comprising:

identifying a local log stream configuration;

receiving transaction log information relating to at least one data store over a plurality of log streams; and

conforming the plurality of log streams to the local log stream configuration by at least one of merging at least one log stream of the plurality of log streams or splitting at least one log stream of the plurality of log streams.

20. The method of claim 19, further comprising:

identifying a series of transactions recorded within the transaction log information; and

reconstructing an operating state of the at least one data store to which the transaction log information relates at least in part by performing the series of transactions on at least one local data store.