Recovery via Rollback/Rollforward
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 rollforward, 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 contains 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-16.
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-17.
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.
Chapter 9 Managing Multiuser Databases
with Changes
Without Changes
Before Images
(a) Rollback
Without Changes
with Changes
(Save)
After Images
Figure 9-16
Undo and Redo Transactions
(b) Rollforward
Relative Record Numbe
Transaction ID
Reverse Pointer
Forward Pointer
Time
Type of Operation
Object
Before Image
After Image
1 OT1 0 2 11:42 START 2 OT1 1 4 11:43 MODIFY
CUST 100
(old value) (new value)
3 OT2 0 8 11:46 START 4 OT1 2 5 11:47 MODIFY
SP AA
(old value) (new value)
5 OT1 4 7 11:47 INSERT
ORDER 11
(value)
6 CT1 0 9 11:48 START 7 OT1 5 0 11:49 COMMIT 8 OT2 3 0 11:50 COMMIT
Figure 9-17
(old value) (new value) Example Transaction Log
9 CT1 6 10 11:51 MODIFY
SP BB
10 CT1 9 0 11:51 COMMIT
Given a log with before images and after images, the undo and redo actions are straight- forward. To undo the transaction in Figure 9-18, the recovery processor simply replaces each changed record with its before image.
When all of the before images have been restored, the transaction is undone. To redo a transaction, the recovery processor starts with the version of the database at the time the transaction started and applies all of the after images. As stated, this action assumes that an earlier version of the database is available from a database save.
Part 4 Multiuser Database Processing
Accept order data from browser. Read CUSTOMER and SALESPERSON records. Change CUSTOMER and SALESPERSON records. Rewrite CUSTOMER record. Rewrite SALESPERSON record.
(Log records written here)
Insert new ORDER record. ****CRASH****
(a) Processing with Problem
Before images of
Database with
CUSTOMER and
new CUSTOMER,
and ORDER records
Recovery Processor (Applies before images of CUSTOMER and SALESPERSON and removes new ORDER record)
Database with ORDER transaction
Figure 9-18
removed
Recovery Example
(b) Recovery Processing
Restoring a database to its most recent save and reapplying all transactions may require considerable processing. To reduce the delay, DBMS products sometimes use checkpoints.
A checkpoint is a point of synchronization between the database and the transaction log. To perform a checkpoint, the DBMS refuses new requests, finishes processing outstanding requests, and writes its buffers to disk. The DBMS then waits until the operating system notifies it that all outstanding write requests to the database and to the log have been success- fully completed. At this point, the log and the database are synchronized. A checkpoint record is then written to the log. Later, the database can be recovered from the checkpoint and only after images for transactions that started after the checkpoint need be applied.
Checkpoints are inexpensive operations, and it is feasible to take three or four (or more) per hour. In this way, no more than 15 or 20 minutes of processing need to be recovered. Most DBMS products perform automatic checkpoints, making human intervention unnecessary.
You will see specific examples of backup and recovery techniques for SQL Server, Oracle Database, and MySQL in the next three chapters. For now, you only need to understand the basic ideas and to realize that it is the responsibility of the DBA to ensure that adequate backup and recovery plans have been developed and that database saves and logs are generated as required.
Managing the DBMS
In addition to managing data activity and the database structure, the DBA must manage the DBMS itself. The DBA should compile and analyze statistics concerning the system’s perfor- mance and identify potential problem areas. Keep in mind that the database is serving many user groups. The DBA needs to investigate all complaints about the system’s response time, accu- racy, ease of use, and so forth. If changes are needed, the DBA must plan and implement them.
Chapter 9 Managing Multiuser Databases
The DBA must periodically monitor the users’ activity on the database. DBMS products include features that collect and report statistics. For example, some of these reports may indicate which users have been active, which files—and perhaps which data items—have been used, and which access methods have been employed. Error rates and types also can be captured and reported. The DBA analyzes these data to determine whether a change to the database design is needed to improve performance or to ease the users’ tasks. If change is necessary, the DBA will ensure that it is accomplished.
The DBA should analyze run-time statistics on database activity and performance. When
a performance problem is identified (by either a report or a user’s complaint), the DBA must determine whether a modification of the database structure or system is appropriate. Examples of possible structural modifications are establishing new keys, purging data, deleting keys, and establishing new relationships among objects.
When the vendor of the DBMS being used announces new product features, the DBA must consider them in light of the overall needs of the user community. If the DBA decides to incorpo- rate the new DBMS features, the developers must be notified and trained in their use. Accordingly, the DBA must manage and control changes in the DBMS as well as in the database structure.
Other changes in the system for which the DBA is responsible vary widely, depending on the DBMS product as well as on other software and hardware in use. For example, changes in other software (such as the operating system or the Web server) may mean that some DBMS features, functions, or parameters must be changed. The DBA must therefore also tune the DBMS product with other software in use.
The DBMS options (such as transaction isolation levels) are initially chosen when little is known about how the system will perform in the particular user environment. Consequently, operational experience and performance analysis over a period of time may reveal that changes are necessary. Even if the performance seems acceptable, the DBA may want to alter the options and observe the effect on performance. This process is referred to as tuning, or optimizing, the system. Figure 9-19 summarizes the DBA’s responsibilities for managing the DBMS product.