DBMS Topics
Recovery System
Last Updated : 21 May, 2026
A recovery system restores the database to a correct, consistent state after a failure. Failures are inevitable — the recovery system ensures data durability and atomicit
Overview
A recovery system restores the database to a correct, consistent state after a failure. Failures are inevitable — the recovery system ensures data durability and atomicity.
Types of Failures
1. Transaction Failure
The transaction itself fails before completing.
Causes:
- Logical error (divide by zero, constraint violation)
- Deadlock detection (transaction chosen as victim)
- User-issued ROLLBACK
Recovery: Roll back (undo) the incomplete transaction using the log.
2. System Failure (Soft Crash)
The system stops unexpectedly, but disk storage is intact.
Causes:
- Power failure
- Operating system crash
- DBMS software bug
Effect: Contents of volatile memory (buffer pool) are lost; disk data survives.
Recovery: Use the transaction log to redo committed transactions and undo incomplete ones.
3. Disk Failure (Hard Crash / Media Failure)
Physical damage to disk storage — data on disk is lost.
Causes:
- Head crash
- Disk corruption
- Catastrophic hardware failure
Recovery: Restore from a full database backup + apply archived logs.
Failure Hierarchy Diagram
| │ Transaction Failure | Undo (rollback) │ |
| │ System Failure | Undo + Redo using log │ |
| │ Disk Failure | Restore from backup + archive log │ |
Storage Types
| Storage Type | Survives System Crash? | Survives Disk Failure? |
|---|---|---|
| Volatile (RAM, buffer pool) | NO | NO |
| Non-volatile (disk, SSD) | YES | NO |
| Stable Storage (RAID, mirrored disk) | YES | YES (with redundancy) |
Stable storage is approximated by writing data to two or more independent disks — if one fails, the other has the data.
Recovery Categories
Undo (Rollback)
Reverses the effects of an incomplete (aborted/failed) transaction.
Transaction T was writing but never committed
Undo all writes made by T using BEFORE-images from log.
Log entry format
<T, X, old_value, new_value>
Undo: write old_value back to X for all entries of T (newest-first)
Redo
Re-applies the effects of a committed transaction whose changes may not have been written to disk before the failure.
What Needs Undo vs. Redo
| Case 1 | T committed BEFORE crash |
| Case 2 | T was active AT THE TIME OF crash (not committed) |
| Case 3 | T committed but AFTER the last checkpoint |
Recovery Manager
The Recovery Manager is responsible for:
| │ | Log written to stable storage BEFORE data page │ |
| │ | Records all BEGIN, WRITE, COMMIT, ABORT events │ |
| │ | Rolls back incomplete transactions after crash │ |
| │ | Re-applies committed but unflushed writes │ |
| │ | Periodically flushes dirty pages to disk │ |
STEAL / NO-FORCE Policy
Two policy choices affect recovery design:
| Policy | Meaning |
|---|---|
| STEAL | Uncommitted data can be written to disk (allows buffer reuse) |
| NO-STEAL | Uncommitted data cannot be written to disk |
| FORCE | All changes must be written to disk at commit |
| NO-FORCE | Changes need not be written to disk immediately at commit |
Most DBMS use STEAL + NO-FORCE (best performance):
- STEAL → May need UNDO for uncommitted writes on disk
- NO-FORCE → May need REDO for committed writes not yet on disk
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Recovery System.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this DBMS topic.
Search Terms
dbms, database management system, database notes, sql, unit, recovery, system, recovery system
Related DBMS Topics