Method and system for controlling recovery downtime

Details Method and system for controlling recovery downtime Method and system for controlling recovery downtime

1998-06-23

2002-02-26

Black, Thomas (Department: 2171)

Data processing: database and file management or data structures

Database design

Data structure types

C714S016000, C714S020000

Reexamination Certificate

active

06351754

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to computer systems and, more specifically, to a method for controlling downtime during the recovery of database systems.
BACKGROUND OF THE INVENTION
Most data processing systems include both volatile and nonvolatile memory devices. In general, volatile memory devices, such as random access memory, provide faster access times than nonvolatile memory devices, such as magnetic or optical disks. However, nonvolatile memory is generally less expensive and less susceptible to data loss.
To take advantage of the persistent nature of nonvolatile memory, an object, such as a data item in a database system, is typically stored on nonvolatile memory (i.e. database) until the object is required by a process. To take advantage of the speed of volatile memory, a copy of the object is loaded into volatile memory when the object is required by a process. Once the object is loaded into volatile memory, the process can quickly access and make changes to the copy of the object. At some later point in time, the copy of the updated object is written back to the database in order to reflect the changes that were made by the process.
For example, in a database system, a section of volatile memory known as a buffer cache is generally used by the processes for accessing and manipulating information contained within the database. In order for a process to access or change data that is stored in the database, a copy of the data is first loaded from the database into the buffer cache. After the data is loaded in the buffer cache, the process can then quickly access and manipulate the copied data version. At some later point in time, the contents of the buffer cache are written back to the database in order to reflect any changes that were previously made to the copied data version.
Typically, the buffer cache includes multiple buffers that are shared among one or more processes that are executing on a database server. When a process executes a transaction that requires a change to an item within a data block, a copy of the data item is loaded into a buffer in the buffer cache. Any changes are then made to the data within the buffer.
Because of the nature of volatile memory, various types of failures can cause the information contained within the buffers to be lost. If the volatile memory contains updated copies of data items, the changes may be lost if a failure occurs before the changes are written back into the database. In many applications, such loss of information is unacceptable.
Therefore, recovery techniques have been developed to reduce the possible loss of information due to failures within a database system. According to one approach, data is made “recoverable” whenever it becomes critical for the data to survive a failure. Data is considered to be “recoverable” when enough information to reconstruct the data after a failure is stored in nonvolatile memory. For example, in database systems it is considered critical that the changes made by a particular committed transaction be reflected within the database and the changes made by a particular aborted transaction be removed from the database.
Redo Records
One method of making the updated data recoverable is to write redo records into a redo log file in nonvolatile memory. The redo records contain a description of the changes that were made by a particular transaction (“change information”) that will enable a recovery process to reapply the changes in the event of a failure.
Specifically, whenever a transaction executes, space is allocated for redo records in both volatile and nonvolatile memory. The redo records are used to store change information about updates that a transaction makes to a particular buffer in the buffer cache. The change information is stored in the redo records in volatile memory and then later copied to nonvolatile memory.
In creating the redo records, a version identifier is associated with each redo record. The version identifier indicates the version of a particular data item associated with the update information contained in a redo record. After the redo record is copied into the redo log file, the version identifier is used in determining whether the data item in the database reflects the changes recorded in the redo record. In addition to the version identifier, each redo record in nonvolatile memory is associated with a byte offset that indicates where the particular redo record is located within the redo log file.
For example,
FIG. 1
illustrates a redo-based recovery mechanism that can be used to perform changes that are recorded in a redo log file
118
in the event of a failure in the database system. As depicted in
FIG. 1
, database
128
and redo log file
118
reside within the nonvolatile memory
101
of database system
100
. Conversely, buffer cache
102
and redo log buffer
112
reside within the volatile memory
103
of database system
100
. Buffer cache
102
contains buffers
104
,
106
,
108
, and
110
which respectively contain data loaded into volatile memory
103
from data items
142
,
134
,
130
and
138
within database
128
. For the purposes of explanation, it shall be assumed that data items
142
,
134
,
130
and
108
are respectively data blocks A, B, C and D from the database
128
.
Contained within redo log buffer
112
are redo records
114
and
116
which describe the changes made to data item
108
by a transaction (TX3). By the time transaction TX3 commits, the information that is contained in redo records
114
and
116
is stored in redo log file
118
as redo records
124
and
120
respectively. The version identifier associated with each redo record is copied into the redo log file and is used in determining whether the associated data item in the database reflects the changes that are recorded in the particular redo record.
Performing Recovery With Redo Records
If a database failure occurs, all information contained in volatile memory
103
may be lost. Such information may include buffers within buffer cache
102
that contain data items that have been updated by transactions, but that had not yet been saved to non-volatile memory
101
. As mentioned above, it is essential for the committed updates made by all such transactions to be reflected in the persistently-stored data items within the database
128
.
To ensure that updates made by transactions are reflected in the database
128
after a failure, redo records in the redo log file
118
are sequentially processed after a failure. A redo record is processed by reading the redo record from the redo log file
118
and then retrieving the data item identified in the redo record. The process performing the recovery (the “recovery process”) then determines if the change specified in the redo record is already reflected in the copy of the data item that is stored in the database
128
. If the change is not reflected in the data item, then the change is applied to the data item. Otherwise, the change is not applied to the data item and the next redo record in the redo log file
118
is processed.
In a conventional redo-based approach to recovery, the recovery process determines whether the change identified in a redo record has already been applied to a data item by reading a version identifier from the data item and comparing the version identifier from the data item to the version identifier stored in the redo record. In a typical database system, determining whether a change identified in a particular redo record has already been applied to a data item requires the overhead of reading a data block that contains the data item into volatile memory and then comparing the version identifier associated with the data item to the version identifier stored in the redo record. If the version identifier stored in the redo record is newer than the version identifier associated with the data item, then the buffer that contained the updated data item had not been written from the buffer cache
102
back to the database
128
prior to the failure. Therefore, the change must b

Affiliated with

Also associated with

Rating

Method and system for controlling recovery downtime 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 system for controlling recovery downtime, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for controlling recovery downtime will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2956746