Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
NO-UNDO REDO Recovery Based on Deferred Update
The concept of deferred update in database management systems (DBMS) involves postponing the actual updates to the database on disk until a transaction successfully completes its execution and reaches the commit point.
During the execution of a transaction, updates are only recorded in the log and in the cache buffers. Once the transaction reaches its commit point and the log is forcefully written to disk, the updates are then recorded in the database. If a transaction fails before reaching its commit point, there is no need to undo any operations because the database on disk remains unaffected. As a result, only REDO-type log entries are necessary in the log, containing the new values (AFIM) of items written by write operations. UNDO-type log entries are not required since there is no need to undo any operations during recovery. However, this approach is practical only for short transactions with few changes, as otherwise, the buffer space may become insufficient to hold transaction changes until the commit point.
A typical deferred update protocol can be described as follows −
A transaction is not allowed to modify the database on disk until it reaches its commit point.
A transaction reaches its commit point only when all REDO-type log entries are recorded in the log, and the log buffer is forcefully written to disk.
It is important to note that step 2 of this protocol essentially reiterates the write-ahead logging (WAL) protocol. Since the database is never updated on disk until after the transaction commits, there is never a need to UNDO any operations. Instead, REDO operations are required if the system fails after a transaction commits but before all its changes are recorded in the database on disk. In such cases, the transaction operations are redone using the log entries during the recovery process.
For multiuser systems with concurrency control, the processes of concurrency control and recovery are closely intertwined. In a system that employs strict two-phase locking for concurrency control, locks on items remain in effect until a transaction reaches its commit point. Only after that, the locks can be released, ensuring strict and serializable schedules. Assuming that checkpoint entries are included in the log, we can outline a possible recovery algorithm for this scenario, referred to as RDU_M (Recovery using Deferred Update in a Multiuser environment).
Procedure RDU_M (NO-UNDO/REDO with checkpoints):
The system maintains two lists of transactions: the committed transactions T since the last checkpoint (commit list) and the active transactions T (active list). The algorithm involves performing a REDO operation on the WRITE operations of the committed transactions recorded in the log, following the order in which they were written.
The active transactions that did not commit are considered effectively canceled and must be resubmitted.
The REDO procedure is defined as follows.
Procedure REDO (WRITE_OP)
Redoing a write_item operation WRITE_OP entails examining its log entry [write_item, T, X, new_value] and setting the value of item X in the database to new_value, which represents the after image (AFIM).
In Figure below, a timeline is presented to illustrate a potential schedule of executing transactions. At time t1, a checkpoint was taken, indicating that transaction T1 had committed, while transactions T3 and T4 had not yet reached their commit points. At time t2, a system crash occurred. Prior to the crash, T3 and T2 had committed, but T4 and T5 had not. According to the RDU_M method described earlier, there is no need to redo the write_item operations of transaction T1 or any transactions committed before the last checkpoint at time t1. However, the write_item operations of T2 and T3 must be redone because both transactions reached their commit points after the last checkpoint.
It is important to recall that the log is force-written to disk before a transaction commits. Transactions T4 and T5 are disregarded in the recovery process as their write_item operations were not recorded in the database on disk under the deferred update protocol. Consequently, these transactions are considered effectively canceled or rolled back.
Handling Aborted Transactions in Deferred Update
To enhance the efficiency of the NO-UNDO/REDO recovery algorithm, we can optimize the process by recognizing that if a data item X has been updated multiple times by committed transactions since the last checkpoint, it is sufficient to REDO only the last update of X from the log during recovery. This is because the previous updates would have been overwritten by this final REDO operation. To implement this optimization, we follow these steps −
Begin from the end of the log and traverse it in reverse order during the recovery process.
Maintain a list of redone items, initially empty.
When an item needs to be redone, check if it is already present in the list of redone items.
If the item is found in the list, there is no need to redo it again, as its last value has already been recovered.
If the item is not in the list, perform the REDO operation to set its value according to the corresponding log entry.
After redoing an item, add it to the list of redone items.
Continue this process until all necessary items have been redone based on the log entries.
By avoiding redundant redo operations on items that have already been recovered, this optimization reduces the overall recovery time and resource utilization.
Advantages and disadvantages
If a transaction is aborted, regardless of the reason (such as deadlock detection), it can simply be resubmitted since it has not made any changes to the database on disk. However, the method described here has certain limitations and considerations. One drawback is that it restricts the concurrent execution of transactions because write-locked items remain locked until the transaction reaches its commit point. Moreover, it may require a significant amount of buffer space to hold all updated items until the transactions are committed. Despite these limitations, the method offers two main advantages −
Transactions do not record any changes in the database on disk until they reach their commit points, which means they are never rolled back due to failures during transaction execution.
Transactions never read the value of an item that is written by an uncommitted transaction since items remain locked until a transaction reaches its commit point. Consequently, there is no occurrence of cascading rollbacks.
2K+ Views
