DBMS Notes
A recovery system restores the database to a correct, consistent state after a failure. Failures are inevitable — the recovery system ensures data...
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.
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
Continue the lesson path