Database Reference
In-Depth Information
updates up to that point are confirmed. In this scenario, the recovery manager is
relieved of the task of reading and processing the entire log file; it only needs to
process log records from the latest checkpoint found on the log file.
Through the use of the recovery manager you can determine how often to take
a checkpoint. While taking a checkpoint, the system has to be paused to perform
the necessary actions of synchronization. Too frequent checkpoints, therefore, inter-
rupt transaction processing. On the other hand, if the checkpoints are too far apart,
the recovery process is likely to become longer. So a proper balance is necessary.
The recovery manager can be made to take a checkpoint at the end of a certain
number of minutes or at the end of a given number of transactions.
Actions at a Checkpoint
At each checkpoint, the DBMS performs the follow-
ing actions:
•
Temporarily suspend executions of transactions.
•
Force-write all modified main memory buffers to the database on secondary
storage.
•
Write a checkpoint record on the log file. A checkpoint record indicates the
transactions that were active at that time.
•
Force-write the log entries in main memory to secondary storage.
•
Resume transaction executions.
Log-Based Recovery Techniques
Assume that a failure has not destroyed the database but has caused inconsistency
problems in the database. Transactions in progress at the time of the failure could
not complete their database updates and commit. These partial updates rendered
the database inconsistent. In such a failure, the recovery process has to undo the
partial updates that have caused inconsistency. Sometimes, it is also necessary to
redo some updates to ensure that the changes have been completed in the database.
The recovery manager utilizes the before and after images of the update operations
as found in the log to restore the database to a consistent state.
Two common methods available for log-based recovery are referred to as the
deferred updates technique and the immediate updates technique. Both techniques
depend on the log records for recovery. They differ in the way updates are actually
made to the database in secondary storage.
Deferred Updates Technique
In this technique, a transaction does not update
the database until after the transaction commits. This means that the transaction
defers or postpones updating the database until after all log entries are completed.
The writing of log records precedes any database update.
Consider a transaction T, performing database operations, and the DBMS writing
log records for the transaction. Let us trace the actions of T.
1. When T starts, write a (T, BEGIN) record on the log file.
2. When T issues a write operation to data item D, write a (T, D, old value, new
value) record on the log file. For the deferred updates technique, the old value
Search WWH ::
Custom Search