Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1998-08-27
2001-01-30
Le, Dieu-Minh T. (Department: 2785)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S015000, C707S793000
Reexamination Certificate
active
06182241
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to database management systems (DBMS). More specifically, the present invention relates to a method and apparatus for recovering after a crash of an instance in a database that allows users to access the database without having to wait for the DBMS to roll back every uncommitted transaction present during system failure.
BACKGROUND OF THE INVENTION
In typical database systems, users store, update and retrieve information by submitting commands to a database application. To be correctly processed, the commands must comply with the database language that is supported by the database application. One popular database language is known as Structured Query Language (SQL).
A logical unit of work that is atomic and comprised of one or more database language statements is referred to as a transaction. In a database server, a memory area called the System Global Area (SGA) is allocated and one or more processes are started to execute one or more transactions. The combination of SGA background system processes and the processes executing transactions is called a database instance.
A buffer cache resides in a portion of the SGA and holds database information. Buffers in the buffer cache hold copies of data blocks that have been read from data files. The buffers are shared by all user processes concurrently connected to the instance. When a transaction desires to make a change to a data block, a copy of the data block is loaded into a buffer and the change is made to the copy of the data block stored in the database buffer cache in dynamic memory. Afterwards, a database writer writes the modified blocks of data from the database buffer cache to the data files on disk.
The SGA also contains a redo log buffer. A redo log buffer is a circular buffer that holds information about update operations recently performed by transactions. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made by operations such as INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP operations for example. Redo entries are generated for each change made to a copy of a data block stored in the database buffer cache. The redo log buffer is written to an active online redo log file group on disk by a background process. The records in the online redo log file group on disk are referred to as redo logs.
An instance failure can occur when a problem arises that prevents an instance from continuing work. Instance failures may result from hardware problems such as a power outage, or software problems such as an operating system or database system crash. Instance failures can also occur expectedly, for example, when a SHUTDOWN ABORT or a STARTUP FORCE statement is issued.
Due to the way in which database updates are performed to data files in some database systems, at any given point in time, a data file may contain some data blocks that (1) have been tentatively modified by uncommitted transactions and/or (2) do not yet reflect updates performed by committed transactions. Thus, an instance recovery operation must be performed after an instance failure to restore a database to the transaction consistent state it possessed just prior to the instance failure. In a transaction consistent state, a database reflects all the changes made by transactions which are committed and none of the changes made by transactions which are not committed.
A typical DBMS performs several steps during an instance recovery. First, the DBMS rolls forward, or reapplies to the data files all of the changes recorded in the redo log. Rolling forward proceeds through as many redo log files as necessary to bring the database forward in time to reflect all of the changes made prior to the time of the crash. Rolling forward usually includes applying the changes in online redo log files, and may also include applying changes recorded in archived redo log files (online redo files which are archived before being reused). After rolling forward, the data blocks contain all committed changes as well as any uncommitted changes that were recorded in the redo log prior to the crash. Rollback segments include records for undoing uncommitted changes made during the roll-forward operation. In database recovery, the information contained in the rollback segments is used to undo the changes made by transactions that were uncommitted at the time of the crash. The process of undoing changes made by the uncommitted transactions is referred to as “rolling back” the transactions.
FIG. 1
illustrates rolling forward and rolling back. Database
110
is a database requiring recovery at time t
1
. Database
120
represents the database after a redo log is applied at time t
2
. The database
120
comprises both changes made by committed transactions
121
and changes made by uncommitted transactions
122
. Database
130
represents the database at time t
3
after a rollback segment is applied. The database
130
comprises only changes made by committed transactions
121
.
When rolling back a transaction, the DBMS releases any resources (locks) held by the transaction at the time of failure. Lastly, the DBMS resolves any pending distributed transactions that were undergoing a two-phase commit coordinated by the DBMS at the time of the instance failure.
One disadvantage of the prior method of recovering after a crash of an instance of a database is that it required changes made by uncommitted transactions to be rolled back before the database could be made available to new transactions. This would take a long period of time when a large number of transactions were active during the instance, because it would require a large number of transactions to be rolled back, including changes to the parts of the database which are not of immediate interest to the users.
SUMMARY OF THE INVENTION
According to one aspect of the invention, a method for recovering after premature termination of a plurality of transactions comprises the steps of: A) selecting a previously unselected transaction from the plurality of transactions; B) processing the selected transaction by undoing the lesser of a predetermined number of changes made by the selected transaction and all changes made by the selected transaction; and C) repeating steps A) and B) until all of the plurality of transactions have been processed.
According to another aspect of the invention, a method for recovering a database after the premature termination of a plurality of transactions comprises the computer implemented steps of: A) selecting a previously unselected transaction from the plurality of transactions, wherein the selected transaction is the previously unselected transaction from the plurality of transactions that made the fewest number of changes in the database; B) processing the selected transaction by undoing one or more changes in the database made by the selected transaction; and C) repeating steps A) and B) until all transactions from the plurality of transactions have been processed.
According to another aspect of the invention, a computer system for recovering after premature termination of a plurality of transactions comprises one or more processors and a memory coupled to the one or more processors. The memory contains one or more sequences of one or more instructions which, when executed by the one or more processors, cause the one or more processors to perform the steps of: A) selecting a previously unselected transaction from the plurality of transactions; B) processing the selected transaction by undoing the lesser of a predetermined number of changes made by the selected transaction and all changes made by the selected transaction; and C) repeating steps A) and B) until all of the plurality of transactions have been processed.
REFERENCES:
patent: 5065311 (1991-11-01), Masai et al.
patent: 5155678 (1992-10-01), Fukumoto et al.
patent: 5201044 (1993-04-01), Frey, Jr. et al.
patent: 5280611 (1994-01-01), Mohan et al.
patent: 5333303 (1994-07-01), Mohan
patent: 5335343 (1994-08-01), Lampson et a
Ngai Gary C.
Rizvi Hasan
Tan Leng Leng
Becker Edward A.
Hickman Palermo & Truong & Becker LLP
Le Dieu-Minh T.
Oracle Corporation
LandOfFree
Method and apparatus for improved transaction recovery 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 improved transaction recovery, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for improved transaction recovery will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2502631