Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-12-03
2001-09-18
Ho, Ruay Lian (Department: 2771)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06292808
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to databases, and more specifically, to a method and apparatus for reapplying changes to a database.
BACKGROUND OF THE INVENTION
Updates to databases are often made by changing data stored in dynamic memory and then writing the changed data to disk at a later time. However, in every database system, the possibility of a system or hardware failure always exists. Such failures can corrupt or destroy changes made to data in dynamic memory before the changed data has been written to disk, leaving the database in an inconsistent state. Even after changed data has been written to disk, media failures can corrupt or destroy portions of a database containing the changed data.
To address the risk of losing changed data not yet written to disk, some contemporary databases maintain a recovery log containing a record of all changes made against the database. The recovery log typically consists of one or more files stored on disk which contain sufficient information about the changes so that in the event of a failure, the changes that were lost during the failure may be made against the database again. Hence, the recovery log provides a recovery mechanism for restoring the consistency of a database in the event of a failure.
Consider the simple database arrangement
100
depicted in
FIG. 1. A
first client application
101
and a second client application
102
submit changes to a database system
103
. The database system
103
includes a database server
104
and non-volatile storage
105
. The database server
104
processes database changes submitted by the first and second client applications
101
,
102
and accesses non-volatile storage
105
which stores the database files. The database system
103
also includes a recovery log
106
which resides on non-volatile storage
105
and contains sufficient information about all of the changes submitted to the database system
103
by the client applications
101
and
102
, so that in the event of a failure, the changes may be resubmitted from recovery log
106
.
Because a failure may occur at any time, it is not known which changes have actually been written to non-volatile storage
105
. Therefore, during recovery, data blocks on the non-volatile storage
105
must be checked to determine whether the data block reflects the changes recorded in the recovery log
106
. According to one approach, this determination is performed by reading a version identifier that indicates the stored version of each referenced data block and comparing the version identifier to a corresponding version identifier stored in the recovery log
106
. If the version identifier associated with the change contained in the recovery log
106
is newer than the version identifier associated with the data block stored on non-volatile storage
105
, then the change was never applied to the data block stored in the non-volatile storage
105
and must be reapplied. On the other hand, if the version identifier associated with the data block stored on non-volatile storage
105
is at least as recent as the version identifier associated with the change contained in the recovery log
106
, then the change does not need to be reapplied.
For changes affecting many data blocks, this process becomes quite time consuming. Moreover, the changes are stored in the recovery log
106
in chronological order. Accessing the data blocks in the database files based upon the chronological order of the changes in the recovery log
106
results in random disk I/O, which is relatively inefficient due to the amount of seek time consumed during the read. This is because the data blocks are sometimes written in different orders.
In view of the need to reapply changes to a database after a system or hardware failure, and the limitations associated with existing approaches, a method and apparatus for reapplying changes to a database to further reduce database recovery time is highly desirable.
SUMMARY OF THE INVENTION
A method and apparatus are provided for reapplying changes to a database. According to one aspect of the present invention, a method is provided for allowing a change to data to be reflected in a database after a failure. A first recovery record is generated which is indicative of the change applied to a copy of the data from the database which is stored in volatile storage. The recovery record is then stored in non-volatile storage. If the copy of data is stored to the non-volatile storage before the failure, then a second recovery record is generated which indicates that the copy of data was stored to the non-volatile storage. The second recovery record is then also stored to the non-volatile storage.
According to another aspect of the present invention, a method is provided for ensuring that a change is reflected in a database. First, a recovery log is created on non-volatile storage which contains sufficient information about the change applied to a first copy of data residing in volatile storage so that the change may be reapplied to a second copy of the data residing in the non-volatile storage. Then a determination is made as to whether the first copy of the data has been written to the non-volatile storage. If the first copy of the data has been written to the non-volatile storage, then the recovery log is updated to indicate that the change does not need to be reapplied to the second copy of the data residing in the non-volatile storage. However, if the change needs to be reapplied, then the change is reapplied to the second copy of the data residing in the non-volatile storage.
According to another aspect of the present invention, a method is provided for ensuring that changes are reflected in a database. The method includes the steps of sorting change information contained in a recovery log and reapplying the changes to the database based upon the sorted change information contained in the recovery log.
According to yet another aspect of the present invention, a system is provided for ensuring that a change is reflected in a database. The system includes one or more nodes, a recovery log residing on the one or more nodes which contains sufficient information about the change so that the change may be reapplied to the database and means for updating the recovery log.
REFERENCES:
patent: 5278982 (1994-01-01), Daniels et al.
patent: 5317731 (1994-05-01), Dias et al.
patent: 5327556 (1994-07-01), Mohan et al.
patent: 5440727 (1995-08-01), Bhide et al.
patent: 5455944 (1995-10-01), Haderle et al.
patent: 5465328 (1995-11-01), Dievendorff et al.
patent: 5809527 (1998-11-01), Cooper
patent: 5832510 (1998-11-01), Ito et al.
patent: 5832511 (1998-11-01), Beck
patent: 5974425 (1999-10-01), Obermarck et al.
Johnson Mark H.
Obermarck Ronald
Becker Edward A.
Hickman Palermo & Truong & Becker LLP
Ho Ruay Lian
Oracle Corporation
LandOfFree
Method and apparatus for reapplying changes to a database does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for reapplying changes to a database, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for reapplying changes to a database will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2483337