Database Reference
In-Depth Information
Backward Recovery
If the database has not actually been destroyed, the problem must involve transactions that were either
incorrect or, more likely, stopped in midstream. In either case, the database is currently not in a valid state.
You can use backward recovery,orrollback, to recover the database to a valid state by undoing the problem
transactions. The DBMS accomplishes the backward recovery by reading the log for the problem transactions
and applying the before images to undo their updates, as shown in Figure 7-13.
245
DBMS backward
recovery feature
Premiere
Products
database
Log
(before images)
DBMS backward recovery
feature uses the log to apply
before images for the
problem transactions
FIGURE 7-13
Backward recovery
Q&A
Question: For the sample log shown in Figure 7-11, what does the DBMS do to roll back transaction 1?
Answer: The DBMS started transaction 1 at 8:00, changed a Part table record at 8:04 for transaction 1, and
committed transaction 1 at 8:06. To roll back transaction 1, the DBMS applies the before image of the Part
table record.
Q&A
Question: For the sample log shown in Figure 7-11, what does the DBMS do to roll back transaction 3?
Answer: The DBMS started transaction 3 at 8:03, added a Customer table record at 8:08 for transaction 3,
and committed transaction 3 at 8:10. Because no before image exists for adding a record, to roll back trans-
action 3, the DBMS deletes the Customer table record.
Recovery on PC-Based DBMSs
PC-based DBMSs generally don
t offer sophisticated recovery features such as journaling. Most of them pro-
vide users with a simple way to make backup copies and to recover the database later by copying the backup
over the database.
How should you handle recovery in any application system you develop with a PC-based DBMS? You could
simply use the features of the DBMS to periodically make backup copies and use the most recent backup if a
recovery is necessary. The more important it is to avoid redoing work, the more often you would make back-
ups. For example, if a backup is made every eight hours, you might have to redo up to eight hours of work. If,
on the other hand, a backup is made every two hours, you might have to redo up to two hours of work.
In many situations, this approach, although not particularly desirable, is acceptable. However, for systems
with a large number of updates made to the database between backups, this approach is not acceptable. In
such cases, the necessary recovery features that are not supplied by the DBMS must be included in the appli-
cation programs. Each of the programs that updates the database could, for example, also write a record to a
separate log file, indicating the update that had taken place. You could write a separate program to read the
log file and re-create all the updates indicated by the records in the file. The recovery process would then
consist of copying the backup over the actual database and running this special program.
'
