Recovering a database to any point-in-time in the past with guaranteed data consistency

• US 8,364,648 B1
• Filed: 04/09/2008
• Issued: 01/29/2013
• Est. Priority Date: 04/09/2007
• Status: Active Grant

• Current Assignee: Quest Software, Inc.
• Original Assignee: Quest Software, Inc.
• Inventors: Sim-Tang, Siew Yong
• Primary Examiner(s): Kerzhner, Aleksandr
• Application Number:
  US12/099,837
• Time in Patent Office: 1,756 Days
• Field of Search: 707/674, 707/999.203
• US Class Current: 707/674
• CPC Class Codes: G06F 16/20 of structured data, e.g. relational data
• CPC Class Codes: G06F 16/2358 Change logging, detection, and notification replication G06F16/27

Abstract

A data management method wherein a real-time history of a database system is stored as a logical representation and the logical representation is then used for any point-in-time recovery of the database system. More specifically, a method for capturing transaction data, binary data changes, metadata, and events, and for tracking a real-time history of a database system according to the events. The method enables tracking and storing of consistent checkpoint images of the database system, and also enables tracking of transaction activities between checkpoints. The database system may be recovered to any consistent checkpoint or to any point between two checkpoints.

Claims

1. A data management method, comprising:

capturing, in real time, complete record changes of a database-system data source along a single data path;

wherein an actual change order of the complete record changes is preserved;

wherein changes to new volumes are captured;

receiving from the database-system data source, as a real-time continuous history of the database-system data source, a real-time event journal;

storing in a data store the real-time continuous history of the database-system data source as a logical representation, wherein consistent checkpoint images of different database versions, real-time event journal versions, and database transactions are stored in association with time stamps indicating when the database versions and journal versions were created and when the transactions occurred; and

using the logical representation for any point-in-time recovery of a data set of the database-system data source, wherein the any point-in-time recovery includes;

choosing a desired point-in-time to which to recover the data set;

identifying, using a first level of indexing that tracks consistent database versions, a closest database version that was created right before the desired point-in-time;

identifying, using a second level of indexing that tracks real-time event journal versions between the consistent database checkpoints, a closest real-time event journal version that was created after the closest database version and right before the desired point-in-time;

identifying, using a third level of indexing that tracks database transactions between the real-time event journal versions, a list of database transactions that occurred after the closest real-time event journal version and before the desired point-in-time; and

restoring the closest database version, restoring the closest real-time event journal version, and rolling forward the database state to the desired point-in-time using the identified list of database transactions.

2. The method as described in claim 1 wherein the data set of the database-system data source comprises data from one or more databases.

3. The method as described in claim 1 wherein the any point-in-time recovery provides recovery with consistency and integrity of one or more database files belonging to a database, where files are versioned at a checkpoint event.

4. The method as described in claim 1 wherein the any point-in-time recovery provides recovery with consistency and integrity of multiple databases each of which are aligned at a checkpoint event.

5. The method as described in claim 1 wherein the any point-in-time recovery provide recovery with consistency and integrity of one or more of database binary files belong to one database with the files versioned at a checkpoint event prior to a recover point-in-time, and one or more database log files belong to the same database with transaction records up to the recover point-in-time.

6. The method as described in claim 5 wherein the any point-in-time recovery provides recovery with guaranteed consistency across multiple databases of the database-system data source, where each database of the multiple databases has one or more volumes.

7. The method as described in claim 1 wherein the any point-in-time recovery provides recovery with consistency and integrity of one or more database volumes that belong to a database, where volume data of the one or more database volumes is versioned at a checkpoint event.

8. The method as described in claim 1 wherein the any point-in-time recovery provides recovery with consistency and integrity of one or more database binary volumes that belong to a database, where the one or more database binary volumes are versioned at a checkpoint event prior to a recover point-in-time, and one or more database log volumes belong to the database with transaction records of the one or more database log volumes up to the recover point-in-time.

9. The method as described in claim 1 wherein the point in-time is when an event occurs in a timeline.

10. The method as described in claim 8 wherein the checkpoint event is one of:

a database event, a user tag, a system event, a network event, and a security event.

11. The method as described in claim 1, wherein recovery includes:

creating a hierarchical data structure of recovering data;

filling content of files or volumes;

allowing a database service to be started instantaneously; and

paging data on demand as requested by the database-system data source.

12. The method as described in claim 1 wherein the capturing is performed using a finite state machine.

13. The method as described in claim 1 wherein the data store is remote from the database-system data source.

14. The method as described in claim 1, wherein the received real-time event journal comprises:

transaction data;

binary data changes;

metadata; and

events.