In deferred update recovery, actual database modifications on disk are postponed until a transaction commits. Updates are recorded only in the log and cache buffers during execution. If a transaction fails before commit, the database on disk remains unaffected hence NO-UNDO. Only REDO is needed for committed transactions whose changes haven't been written to disk.
Deferred Update Protocol
- A transaction cannot modify the database on disk until it reaches its commit point.
- All REDO log entries must be force-written to disk before commit (Write-Ahead Logging).
- Only REDO log entries (new values/AFIM) are needed no UNDO entries required.
Recovery Procedure (RDU_M)
For multiuser systems with strict two-phase locking, the recovery algorithm maintains two lists
- Commit list Transactions committed since the last checkpoint.
- Active list Transactions that were still active (not committed).
REDO is applied to committed transactions' WRITE operations in log order. Active (uncommitted) transactions are effectively canceled and must be resubmitted.
Example Timeline
Checkpoint (t1) Crash (t2) T1 (committed) T2 → REDO T3 → REDO T4 → Ignored (no commit) T5 → Ignored (no commit)T1 committed before checkpoint no redo needed. T2, T3 committed after checkpoint must be redone. T4, T5 never committed ignored (no changes on disk under deferred update).
REDO Optimization
If item X was updated multiple times by committed transactions, only the last update needs to be redone
- Traverse the log in reverse order.
- Maintain a list of already-redone items.
- Skip items already in the list (last value already recovered).
- REDO only items not yet in the list, then add them.
Advantages and Limitations
Conclusion
NO-UNDO/REDO deferred update postpones disk writes until commit, eliminating the need for UNDO operations during recovery. Only committed transactions after the last checkpoint need REDO. This simplifies recovery but limits concurrency and requires sufficient buffer space to hold all uncommitted changes.
