Database Recovery (Short Note) — Crash Recovery Using WAL and ARIES
Database recovery is the set of mechanisms a DBMS uses to restore a consistent database state after failures such as crashes, power loss, or system restarts. The central idea is that durability and atomicity must be preserved: committed transactions should remain reflected in the database, and uncommitted transactions must not.
A widely used foundation for recovery is Write-Ahead Logging (WAL). With WAL, every update is first written to the log (often with an LSN—log sequence number), so after a crash the system can determine which actions were committed and which must be undone/redone. Most practical systems then follow a restart (crash recovery) procedure, typically optimized using Checkpointing and implementing recovery phases such as analysis, redo, and undo (commonly described in ARIES).
Key terms to remember (for a short note): WAL, checkpoints, redo/undo, and ARIES (or more generally, crash-restart recovery).
ARIES Crash Recovery (WAL + analysis/redo/undo)
Why recovery is necessary
Transactions execute with concurrency and caching, so the DBMS may keep dirty pages in memory that haven’t yet been written to disk. After a crash:
- Some changes from committed transactions might have made it to disk; others might not.
- Some changes from uncommitted transactions might have been partially written.
- The in-memory log of operations is lost, but the stable log (written using WAL) remains available.
Recovery must therefore enforce:
- Redo any actions needed for committed transactions (idempotently, using LSN/page state).
- Undo any actions from transactions that were not committed at crash time.
Pro Tip for your exam short note
Write 4 lines: (1) WAL guarantees log-before-data, (2) crash recovery uses restart, (3) redo committed / undo uncommitted, (4) checkpoints reduce work. Mention ARIES if allowed.
Crash Recovery Workflow (WAL + ARIES-style phases)
- 1Step 1
Identify a checkpoint record to reduce how much log must be examined. If checkpoints are fuzzy, recovery still uses them as starting points.
- 2Step 2
Scan the log from the checkpoint forward to reconstruct: which transactions were active at crash time (losers) and which were committed (winners). Build data structures (e.g., tracking last LSN per page/transaction).
- 3Step 3
Reapply logged actions for pages/records whose effects might not be present on disk. Use LSN comparisons so redo is idempotent (repeating redo should not corrupt state).
- 4Step 4
Roll back actions of loser (uncommitted) transactions by traversing their log records backward. During undo, compensation log records may be written so the undo work itself is recoverable.
- 5Step 5
After undo completes, write end/complete markers as needed and resume transaction processing from a consistent state.
Short, correct explanation of WAL and its role
Write-Ahead Logging (WAL) ensures recoverability. If the DBMS forces the log record for an update before allowing the page update to be written to disk, then after a crash the log contains a complete (or sufficient) history to decide what must be redone or undone.
Intuition:
- If an update was committed, its log records exist on stable storage, so recovery can ensure the update’s effects appear.
- If an update wasn’t committed, recovery can find and remove its effects using undo, preserving atomicity.
Recovery responsibilities: committed vs uncommitted work
A quick way to remember what redo/undo should do.
Common pitfalls & exam-friendly clarifications
How crash recovery typically evolves
Transactions execute
Normal operationUpdates generate log records; pages may be cached (not yet written)."
System crash
FailureMemory state lost; stable storage retains forced log records."
Restart recovery
RestartAnalysis → Redo → Undo using WAL and checkpoints."
Consistency restored
Recovery completeCommitted effects present; uncommitted effects removed."
Knowledge Check
In crash recovery, WAL primarily ensures that…