Managing Multiuser Databases - Database Processing: Fundamentals, Design, and Implementation - page 416

Recovery via Reprocessing
Because processing cannot be resumed at a precise point, the next best alternative is to go
back to a known point and reprocess the workload from there. The simplest form of this type
of recovery is to periodically make a copy of the database (called a database save ) and to keep
a record of all transactions that have been processed since the save. Then, when there is a
failure, the operations staff can restore the database from the save and then reprocess all the
transactions. Unfortunately, this simple strategy is normally not feasible. First, reprocessing
transactions takes the same amount of time as processing them in the first place did. If the
computer is heavily scheduled, the system may never catch up.
Second, when transactions are processed concurrently, events are asynchronous. Slight
variations in human activity, such as a user reading an e-mail before responding to an appli-
cation prompt, can change the order of the execution of concurrent transactions. Therefore,
whereas Customer A got the last seat on a flight during the original processing, Customer B
may get the last seat during reprocessing. For these reasons, reprocessing is normally not a
viable form of recovery from failure in concurrent processing systems.
Recovery via Rollback/Rollforward
A second approach is to periodically make a copy of the database (the database save) and to
keep a log of the changes made by transactions against the database since the save. Then,
when there is a failure, one of two methods can be used. Using the first method, called rollfor-
ward , the database is restored using the saved data, and all valid transactions since the save
are reapplied. (We are not reprocessing the transactions because the application programs
are not involved in the rollforward. Instead, the processed changes, as recorded in the log, are
reapplied.)
The second method is rollback . With this method, we undo changes made by erroneous
or partially processed transactions by undoing the changes they have made in the database.
Then the valid transactions that were in process at the time of the failure are restarted.
Both of these methods require that a log of the transaction results be kept. This log con-
tains records of the data changes in chronological order. Transactions must be written to the
log before they are applied to the database. That way, if the system crashes between the time
a transaction is logged and the time it is applied, at worst there is a record of an unapplied
transaction. If, however, the transactions were to be applied before they were logged, it would
be possible (as well as undesirable) to change the database but have no record of the change. If
this happened, an unwary user might reenter an already completed transaction. In the event of
a failure, the log is used both to undo and to redo transactions, as shown in Figure 9-17.
To undo a transaction, the log must contain a copy of every database record (or page)
before it was changed. Such records are called before images . A transaction is undone by
applying before images of all of its changes to the database.
To redo a transaction, the log must contain a copy of every database record (or page) after
it was changed. These records are called after images . A transaction is redone by applying
after images of all of its changes to the database. Possible data items in a transaction log are
shown in Figure 9-18.
In this example log, each transaction has a unique name for identification purposes.
Furthermore, all of the images for a given transaction are linked together with pointers. One
pointer points to the previous change made by this transaction (the reverse pointer), and
the other points to the next change made by this transaction (the forward pointer). A zero
in the pointer field means that this is the end of the list. The DBMS recovery subsystem uses
these pointers to locate all of the records for a particular transaction. Figure 9-17 shows an
example of the linking of log records.
Other data items in the log are the time of the action; the type of operation (START marks
the beginning of a transaction and COMMIT terminates a transaction, releasing all locks that
were in place); the object acted on, such as record type and identifier; and, finally, the before
images and the after images.
Given a log with before images and after images, the undo and redo actions are straight-
forward. To undo the transaction in Figure 9-19, the recovery processor simply replaces each
changed record with its before image.