Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1996-05-20
2002-04-23
Choules, Jack (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06377959
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to database recovery procedures and specifically to a dual database system that employs concurrent copy and update operations to recover from failure of either database without interrupting availability of the other database.
2. Discussion of the Related Art
An integral part of any database system is a recovery scheme for the detection of failures and the restoration of the database to a consistent state. A “transaction” is a logical unit of work referencing a sequence of queries (reads) and updates (writes, including deletes, inserts, and changes) that transforms a consistent state of a recoverable resource into another consistent state without necessarily preserving consistency at all intermediate points. For the purposes of this discussion, a database is considered as a typical instance of such a recoverable source.
Transactions are executed on computer-implemented database processing systems that may be considered to operate in several modes, including a “processing” mode and, in the event of failure, one or more “recovery” modes. The existing art is replete with examples of fault-tolerant, transaction-oriented database processing systems, including checkpoint and incremental recovery log systems, shadow-paging systems and redundant database systems.
The redundant database systems known in the art are exemplified by the system disclosed in U.S. Pat. No. 5,170,480 issued to Mohan et al. who disclose a synchronous distributed database system that provides for storing a consistent copy of a database in two locations. Mohan et al. teach the use of a tracking system that operates in conjunction with an “active” database system to maintain a “tracking” database in a second redundant database system, where the tracking database is a replica of the active database maintained in the active database system. The transaction log redo records are organized into queues representing separate units of transfer (pages) before transmission from the active database system to the redundant database system, thereby more efficiently maintaining tracking database consistency. Their dual database system permits updating of the active database even when the tracking database is not available and eliminates the usual requirement for independent serialization of redundant database system operations.
When failure occurs in the active database system of a dual database system such as that described by Mohan et al., a redundant database is available as a checkpoint for recovery of the active database in conjunction with the usual transaction log forward recovery procedures known in the art. Unfortunately, neither database is available for active use during such a recovery. Moreover, if one of the two database systems is down for a significant period of time, the size of the forward recovery transaction log necessary for recovering the failed database can grow to unacceptably large size. This is because the forward recovery log must maintain a record of all transactions occurring during the failure period, which are then applied to the recovered consistent database to bring it up to a concurrent consistent state. Alternatively, a failed database can be recovered merely by making a new copy of the redundant database following repair of the active database system failure. However, when the redundant database is remotely located from a very large active database, the mechanics of copying the entire database to the remote location may present unacceptable difficulties. For instance, to ensure consistency, the active database must normally be locked until completion of the database copying process. Thus, all incoming transactions must be accumulated until the active database is unlocked and this accumulation may reach unacceptably large size.
Practitioners have proposed solutions to these problems with only limited success. For instance, in European patent EP-51690-A, Baker et al. disclose an invention that permits a backup to be taken of a nonredundant database while that database remains open for transaction processing by frequently recording a complete set of tie-up records in the transaction log. The tie-up records provide sufficient data to recover a checkpoint database copy, and the high checkpoint frequency permits recovery from a relatively small log upon failure. Thus, Baker et al. do not avoid the usual database system suspension during forward recovery upon failure. Although Baker et al. show how to avoid suspending database operation during checkpoint backup copying, the dual database system also solves this problem by continuously maintaining the redundant database.
Accordingly, there is a clearly-felt need in the art for a dual database system that maintains two databases with identical entries for fault tolerance, where the “active” database is always available during and after system failures. Such a system must permit failure repair without interrupting system operation and must also provide means for recreating the failed backup database following repair without interrupting system operation. That is, the “active” database must remain available for normal system queries and updates while the “redundant” database is being recreated following repair of a system failure. The recreated “redundant” database must reflect all intervening updates made to the active database during recovery, thereby arriving at a concurrent consistent state following such recovery.
The usual practice known in the art for forward recovery from an earlier consistent (checkpoint) database copy using a log of subsequent transactions cannot solve these problems. First, if the failed database is down too long, the forward recovery log becomes too large to permit recovery of a current consistent database from the earlier checkpoint copy. Secondly, incoming transactions cannot be processed during forward recovery and must be accumulated, making the necessary forward recovery log even larger. Finally, if the forward recovery log is frozen, then the entire database system must be halted during forward recovery, which interrupts continuous availability.
These unresolved problems and deficiencies are clearly felt in the art and are solved by this invention in the manner described below.
SUMMARY OF THE INVENTION
This invention provides a continuously-available fault-tolerant database by combining the copy operations necessary to reconstruct a failed database with the database transaction operations incoming during recovery. Thus, the “active” (surviving) database system copies one record at a time while interleaving updates into the operation stream at the “redundant” (recovering) database system. These concurrent redundant database system operations are queued and interleaved with the normal active database transaction processing operations according to a queue thresholding test. When the copying completes, the redundant database is fully recovered into a concurrently consistent state and the continuing (echoed) incoming update operations in the redundant database system serve to maintain the concurrent consistency of the redundant database until another failure occurs. This invention requires interchangeability of the operating status (active or redundant) of each of two database systems and identifiability of each database record by some unique Record Identification Key (RIK).
It is an object of this invention to provide a dual database transaction processing system that is continuously available during recovery from the failure of either of two database processing systems. It is an advantage of the system of this invention that transaction processing activities can be continued uninterrupted during the failure of either database system and also during recovery of the failed database.
It is another objective of the system of this invention to minimize requisite transaction log size and complexity. It is a feature of the dual database system of this invention that transaction log entries are required only during the failure of either databa
Choules Jack
Dan Hubert & Assoc.
International Business Machines - Corporation
LandOfFree
Redundant database recovery through concurrent update and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Redundant database recovery through concurrent update and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Redundant database recovery through concurrent update and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2911443