A server crashes while a transaction is partially completed. How does log-based recovery restore consistency?
Interview preparation resource from Gate Smashers.
After a crash, log-based recovery examines the transaction log to determine which changes to REDO and which to UNDO. Committed transactions are preserved (their updates are REDONE if necessary), while partial updates from uncommitted transactions are removed (UNDONE). Checkpoint information reduces how much of the log must be scanned. This process ensures Atomicity (no partial transactions remain) and Durability (committed work can be restored even if pages were not yet written).
Overview
After a server crash, log-based recovery uses records written to the transaction log during normal processing to restore database consistency. The process distinguishes committed work, which must be preserved, from incomplete uncommitted work, which must be removed.
Role of the log
During normal transaction processing the DBMS records enough information in a log to describe important changes. Depending on the recovery design, log records may contain before values, after values, or other information needed to repeat or reverse an operation.
After a crash, the database examines these log records and the recorded transaction states to determine the appropriate recovery actions.
- Before values: May be recorded so operations can be reversed (UNDO).
- After values: May be recorded so operations can be repeated (REDO).
- Other information: Any additional metadata needed to repeat or reverse an operation.
Recovery actions: REDO and UNDO
The recovery process uses the log to perform REDO for committed work that might not have been written to durable storage, and UNDO for partial updates from transactions that did not commit before the crash.
- Committed transaction: Its updates may need REDO if the log shows they committed but some modified data pages had not yet been written to durable storage.
- Uncommitted transaction: Its partial updates must be UNDO so incomplete work does not remain in the database.
- Checkpoint information: Helps the DBMS reduce how much of the log must be examined during recovery.
Correctness and implementation note
This recovery process enforces Atomicity because incomplete transactions do not remain partially applied, and Durability because committed work can be restored even if the latest data pages were not fully written before the crash.
The exact recovery algorithm differs across DBMS implementations, but REDO of committed work when needed and UNDO of incomplete work is the central idea.