System and method for stopping updates at a specified timestamp in a remote duplicate database facility

• US 5,799,322 A
• Filed: 01/30/1997
• Issued: 08/25/1998
• Est. Priority Date: 01/24/1995
• Status: Expired due to Fees

• Current Assignee: Hewlett-Packard Development Company, L.P. (HP Inc.)
• Original Assignee: Tandem Computers Incorporated (HP Inc.)
• Inventors: Mosher, Malcolm Jr.
• Primary Examiner(s): Lintz, Paul R.
• Application Number:
  US08/790,542
• Time in Patent Office: 572 Days
• Field of Search: 707/201, 707/202, 707/204, 395/182.14
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1471 involving logging of persistent data for recovery
• CPC Class Codes: G06F 11/2066 Optimisation of the communication load
• CPC Class Codes: G06F 11/2074 Asynchronous techniques
• CPC Class Codes: G06F 11/2082 Data synchronisation
• 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 16/275 Synchronous replication
• CPC Class Codes: G06F 2201/80 Database-specific techniques
• CPC Class Codes: Y10S 707/99952 Coherency, e.g. same view to multiple users
• CPC Class Codes: Y10S 707/99953 Recoverability

Abstract

A primary computer system has a database, application programs that modify the local database, and a transaction manager that stores audit records in a local audit trail reflecting those application program modifications to the local database. A plurality of parallel backup systems are used to provide "triple contingency protection" of the data on the primary computer system. However, if the primary system suffers a sudden catastrophic failure, the parallel backup systems will generally be left in inconsistent states. To restart the application programs on one of the backup system, the parallel backup are first synchronized with each other, and then transaction processing is restarted with one of the backup systems as the new primary system, and the other backup systems as the backups to the new primary system. In addition, in order to enable any single backup system'"'"'s database to be brought into a self consistent state, backup volume Updaters are stopped after database updates for all transactions committed on the primary system before a specified time have been completely applied to the backup system'"'"'s database. After any reports requiring a self consistent database have been generated, operation of the Updaters is resumed.

Claims

1. A distributed computer database system, comprising:

a local computer system having a local database stored on local memory media, application programs that modify the local database, and a transaction manager that stores audit records in a master audit trail (MAT) reflecting those application program modifications to the local database;

the audit records in the MAT including A) commit/abort records each having transaction identifier, a transaction commit/abort status indicator, and a commit/abort timestamp indicating when a transaction associated with the transaction identifier committed or aborted, and B) database update records each having a transaction identifier and database modification information;

a remote computer system, remotely located from the local computer system, the remote computer system having a backup database stored on memory media associated with the remote computer system;

a communication channel for sending messages between the local computer system and the remote computer system;

a remote data duplication facility (RDF), partially located on the local computer system and partially located on the remote computer system, for maintaining virtual synchronization of the backup database with the local database, the remote data duplication facility (RDF) including;

an Extractor process executed by the local computer system that extracts audit records from the MAT, constructs a corresponding stream of image records by adding supplemental information to at least some of the audit records, the added information including an image record timestamp, and transmits the stream of image records to the remote computer system;

the image records including commit/abort image records and database update image records;

a Receiver process executed by the respective remote computer system that receives the image records transmitted by the Extractor process, and distributes the received image records to one or more image trails in the respective remote computer system; and

one or more Updater processes executed by the respective remote computer system, wherein each Updater process reads the image records in an assigned one of the image trails and applies at least a subset of the read image records against the backup database by initiating redo operations of the database modifications denoted the subset of the read image records against the backup database;

wherein each Updater process includes Stop Updaters at Timestamp instructions for preventing the Updater from applying against the backup database those of the read database update image records whose transaction ID matches the transaction ID in a corresponding commit/abort image record having a commit/abort timestamp whose value is not earlier than a specified Stop Timestamp.

2. A system as in claim 1, wherein the Stop Updaters at Timestamp instructions include instructions for shutting down each Updater when it first reads a database update image record whose image record timestamp is not earlier than the specified Stop Timestamp.

3. A system as in claim 2, wherein the Stop Updaters at Timestamp instructions include instructions for durably storing a Restart image trail position comprising a pointer to a first database update image record read by the respective Updater process having image record timestamp that is not earlier than the specified Stop Timestamp, each Updater processing including instructions for reading image trail records beginning at the Restart image trail position whenever the Updater process is restarted, whereby database update image records whose application to the backup database was prevented by the Stop Updaters at Timestamp instructions are applied to the backup database whenever the Updater process is restarted.

4. A system as in claim 3, wherein the Stop Updaters at Timestamp instructions include instructions for setting and durably storing a crash recovery flag in each Updater process for shutting down the Updater process, each Updater processing including crash recovery instructions, responsive to the crash recovery flag for the Updater process being set, for suppressing error messages that would otherwise be generated when database updates already applied to the backup database are applied to the backup database a second time.