Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-02-23
2004-05-04
Corrielus, Jean M. (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C714S020000, C714S016000
Reexamination Certificate
active
06732123
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention concerns the recovery of databases using log data sets from multiple database subsystems. More particularly, the invention relates to the merging of log data to recover database data sets to any point in time in a single pass of the log data.
2. Description of the Related Art
Data processing systems typically require a large amount of data storage. Customer data, or data generated by users within the data processing system, usually occupy a great portion of this data storage. Effective data processing systems also provide back-up copies of this user data to insure against a loss of such data. For most businesses any loss of data in their data processing systems is catastrophic, severely impacting the success of the business. To further protect customer data, some data processing systems extend the practice of making back-up copies to provide disaster recovery. In disaster recovery systems, a recovery copy of the customer data is kept in a location separate from the primary location. If a disaster strikes the primary storage location, the customer data can be “recovered” from the recovery copies located in the separate location.
In general, database activity is based on being able to “commit” updates to a database. A commit point is when database updates become permanent. Commit points are events at which all database updates produced since the last commit point are made permanent parts of the database. The span of time between commit points is referred to as a “unit of recovery” (UOR). If something goes wrong, such as a write error to the database, and the updates can not be made, all the updates produced since the last commit point are “aborted.” It is as if the updates never happened.
There are various techniques to implement database updates and commit point processing. One way is for updates always to be applied to a database as they are produced. Copies of the database data from both before and after the change are written to a log. If the updates need to be aborted, the log record is retrieved and the copies of the unchanged database data are applied, in effect backing out the changes.
An alternate way to implement database updates and commit point processing is for the database manager to maintain the database changes in storage and not apply them to the databases until the commit point is reached. A copy of the database data that is changed is written to the log as the update is created. When the commit point is reached, and everything went as expected, the updates are written to the databases. If something went wrong, the storage containing the database updates is freed.
As database use has grown, customers have converted their computer operations to multiple shared system environments. In these environments, information management system (IMS) subsystems using multiple console support (MCS) consoles or extended MCS consoles have found wide use. The MCS consoles are used to receive messages and send data and commands across systems. In the event of a database failure, recovery is required to restore each shared database to a useful condition.
For example, one current method for recovery for these shared databases is to periodically run an IMS utility to accumulate changes to critical database data sets in a change accumulation data set. These change accumulation database data sets are used as input during database recovery. In order to create the change accumulation data, the change accumulation utility reads log data sets sequentially, that is, one after another. Typically, customers organize their multiple databases into change accumulation groups so that use of change accumulation operates as efficiently as possible. A customer can run change accumulation against one change accumulation group and use an optional secondary output—the set of log records that were not written to the change accumulation data set—as input to the change accumulation utility for the next change accumulation group to be processed. This can be done for each change accumulation group in which the current change accumulation run uses the secondary output of the previous change accumulation run. This serial process is managed directly by the customer. Customers usually run change accumulation periodically so that when a database data set in a change accumulation group requires recovery, the time required to run a final change accumulation job and subsequent database recovery job is minimized. This sequential recovery process is quite complex.
Furthermore, customers with large amounts of data to process have problems in addition to operational complexity when recovery is required using current sequential recovery methods. An additional problem arises because the data to be recovered is shared between multiple IMS subsystems. Change accumulation merges and sorts a set of log records so that updates can be applied to database data sets in sequence during recovery. However, as the amount of log data increases, so does the amount of system resources such as CPU time, storage utilization, secondary storage, elapsed clock time, etc., required for accumulating and sorting the updates read from the log data sets. In some cases, so much system resource is required that recovery adversely affects normal system and IMS activity. Running change accumulation while a database requires recovery can also take longer than a user can afford to have critical databases unavailable.
Additionally, certain types of errors can effect more than one database in ways that are not as obvious as a media failure. A customer may only know that as of a specific time, some action caused an error or errors that spanned multiple databases and rendered them unusable. For example, invalid data might have been entered by a system operator; a batch job may have been run more than once; or, an application program may have experienced an error which caused invalid data to be stored into multiple databases. Recovery from these types of errors is laborious, time consuming, and error prone. Typically, an earlier copy of the database data set is used as a base to restore the database to its state prior to the errors which occurred. Subsequent updates would then be applied to the database data set from records on log data sets.
Recovery of a database for these types of errors currently uses a technique referred to as time stamp recovery. Database updates are applied to a database from the time of the database back-up copy to a time when the database was taken off-line. The time the database was off-line may be hours or days prior to when the error occurred. This results in valid updates never being applied to the databases. The loss of this data using standard time stamp recovery techniques can be catastrophic to a customer's business and even more damaging than the unavailability of the database during the down time.
What is needed is a simplified database recovery method and apparatus that reduces the time that “broken” databases are unavailable. The method and apparatus should recover multiple database data sets simultaneously. The method and apparatus should further be able to recover database data sets to any user specified point in time to minimize the loss of data if a recovery to a time stamp is required to eliminate bad data from the database data sets. The method and apparatus should simplify the recovery process, reduce the time the databases are unavailable, and simplify day to day operation procedures. Preferably, change accumulation—creating compacted log data sets by eliminating records in the log not related to recovery of a specified set of database data sets, or merging multiple changes to a data object into a single change—and the need to run separate recovery jobs for each database data set requiring recovery would also be eliminated.
SUMMARY OF THE INVENTION
Broadly, the present invention concerns the merging of log data for recovering one or more database data sets in a single pass of the respective log data.
In one embodiment, the inven
Moore David Wayne
Ranson Karen Alicia
Sullivan Lawrence Edward
Terry Donald Prentiss
Vance Gregory Walter
Corrielus Jean M.
International Business Machines - Corporation
Sawyer Law Group LLP
LandOfFree
Database recovery to any point in time in an online... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Database recovery to any point in time in an online..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Database recovery to any point in time in an online... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3233010