Crash Recovery in DBMS: Write-Ahead Logging and Checkpoints | Part 8

Updated October 12, 2026. General BTech CSE exam notes, not an official university syllabus. The worked log and practice answers are original teaching examples checked with a program. Recovery rules depend on the algorithm; simple undo/redo and ARIES are separated below.

A commit message is useful only if the committed result survives a failure. Crash recovery is the DBMS work that restores a valid database after interrupted execution: preserve durable committed work and remove unfinished work. Recovery supports atomicity (all-or-nothing transaction effects) and durability (committed effects survive a crash). Isolation during ordinary execution is a different problem.

Previous: Part7: Concurrency and Isolation. Next: Part9: Indexes and B+ Trees.

1. Failure types: what remains available?

Failure	Example	What recovery must address
Transaction failure	Constraint violation, explicit abort, deadlock victim	Undo this transaction's incomplete effects. The entire server need not fail.
System crash	Power loss or DBMS/OS crash	Volatile memory may be lost. This model assumes data and durable log storage survive.
Media failure	Lost or damaged storage	Logs on the failed device may also be lost. Restore a usable backup and required archived log, according to the DBMS.

Do not write "all disk content always survives" for every failure. That is a system-crash assumption, not a media-failure guarantee.

2. Buffer pool, dirty page and log

A buffer pool holds database pages in memory. A dirty page has changes not yet written to its disk copy. A log record describes an action needed for recovery. In a simple value-update model it records transaction ID, item, old value and new value. Real DBMS logs can contain other record types and physical or logical information; not every log is that five-field format.

Writing a data page and committing a transaction are different events. A page can hold updates from several transactions, and a committed update may remain only in memory plus durable log until the page is written later.

3. Write-ahead logging: log first

WAL means the relevant durable log must precede the data-page write. For an update with log sequence number LSN, the DBMS must flush log through that update before writing the changed page. Before reporting a durable commit, it must make the transaction's required log records, including commit, durable under that DBMS's durability settings.

Update in memory + log buffer→ Flush required log→ Page may reach disk

The commit record must also be durable before durable success is acknowledged. LSN is an ordered log sequence number. pageLSN records the last logged update reflected on a page. flushedLSN tracks durable log progress. WAL requires pageLSN ≤ flushedLSN before a page flush. Writing every data page at commit is not required by no-force.

4. Undo versus redo

Point	Undo	Redo
Purpose	Remove effects that must not survive	Restore an action absent from the durable page
Simple value log	Restore old value	Apply new value
Order in the simple model	Reverse update order	Forward update order
Concern	Atomicity	Durability/reconstruction
Important exception	ARIES undoes losers after repeating history	ARIES redo may include loser updates, then undo removes them

5. Steal/no-steal and force/no-force

Steal permits a dirty page containing uncommitted updates to reach disk. This creates an undo requirement. No-steal prevents those uncommitted page effects from reaching disk in this teaching policy model. Force requires the transaction's relevant data-page effects on disk at commit. No-force allows them to be written later, creating a redo requirement.

Policy pair	Undo needed for uncommitted disk effects?	Redo needed for committed missing pages?
No-steal + force	No, under these assumptions	No, under these assumptions
No-steal + no-force	No	Yes
Steal + force	Yes	No
Steal + no-force	Yes	Yes

These answers concern crash recovery under the stated policies, not "this DBMS never needs a log". Logging can still support other tasks. Steal/no-force allows flexible page writes but requires stronger recovery machinery.

6. Original worked log: simple undo/redo model

Assume single-item assignment updates, durable log through LSN9, no conflicting interleaved updates to the same item, and a surviving disk. At crash, disk has A=100, B=260, C=30, D=5. B contains an uncommitted update written early; committed A and C are not yet on disk.

LSN1: start T1
LSN2: T1 updates A: 100 → 150
LSN3: start T2
LSN4: T2 updates B: 200 → 260
LSN5: commit T1
LSN6: start T3
LSN7: T3 updates C: 30 → 45
LSN8: commit T3
LSN9: T2 updates D: 5 → 9
CRASH

1. Classify: T1 and T3 have durable commits, so they are winners. T2 has no commit, so it is a loser.
2. Redo winners in this simple model: apply A=150 and C=45.
3. Undo T2 backward: restore D=5, then B=200. D may already be5 on disk; setting the old value again is harmless for this assignment example.

Final: A=150, B=200, C=45, D=5. The program-run result is the same. Do not apply "redo winners only" as a universal ARIES rule.

7. ARIES: analysis → redo history → undo losers

ARIES is a recovery approach commonly taught for steal/no-force systems. Its key ideas are WAL, repeating history during redo, and logging undo actions. The phases have different jobs:

Analysis: identify state→ Redo: repeat history→ Undo: remove losers

• Analysis: reconstruct transaction and dirty-page information from checkpoint/log data. The transaction table tracks active/recovery work; the dirty-page table tracks pages that may need redo.
• Redo: restore relevant logged actions, including actions of transactions that will later be undone. Page/log tests skip changes already present.
• Undo: reverse loser updates using their log chains, and record compensation log records.

Using our same simple value assignments to illustrate repeating history, redo all five updates would temporarily produce A=150, B=260, C=45, D=9. Undo T2 changes D back to5 and B back to200, giving the same final database. This illustrates the idea, not a complete ARIES pageLSN/CLR implementation.

8. LSN, dirty-page table and compensation records

recLSN is the earliest update that made a page dirty for its current dirty period. The redo scan can start from the minimum recLSN in the reconstructed dirty-page table, which can be earlier than the checkpoint. prevLSN links a transaction's log records. A CLR (compensation log record) records an undo action; it is redoable and is not itself undone. Its undoNextLSN helps a restarted recovery avoid undoing the same completed action again.

Example redo test: a log record has LSN70. If the durable pageLSN is80, that action is already reflected, so skip it. If pageLSN is60, redo may be needed, but still check dirty-page-table membership and recLSN. One comparison alone is not the whole ARIES algorithm.

9. Checkpoint is not always a full-page flush

Point	Simple blocking/non-fuzzy checkpoint	ARIES fuzzy checkpoint
Transactions	May pause and wait for active work to finish, depending on scheme	Can continue during checkpoint
Stored information	Consistent checkpoint state under that scheme	Checkpoint log information, transaction/dirty-page state
Dirty pages	A simple scheme flushes them	Does not require every dirty page to be flushed at checkpoint
Recovery scan	Depends on what was made durable	Analysis starts from checkpoint; redo may begin earlier at min recLSN

A checkpoint reduces recovery work. It does not replace backups, and "everything committed before the last checkpoint never needs redo" is not safe without knowing the checkpoint algorithm.

10. Media recovery and backups

If durable pages or log storage are destroyed, crash-recovery assumptions fail. Use a valid backup plus the necessary retained/archived log for the DBMS's supported restore route. Storing a log on a different disk can reduce one device's shared failure risk, but does not protect against every server, site or human failure. Test restoring backups; a backup file that cannot be restored is not a completed recovery plan.

11. Common mistakes

• Mixing durable commit with all data pages flushed.
• Using the simple winners-only redo rule in ARIES.
• Undoing assignment updates in forward rather than reverse order.
• Treating every checkpoint as a full flush.
• Ignoring the stated disk state, durable log boundary or recovery model.
• Using a checkpoint as the answer to a destroyed disk without backup.

12. Seven practice questions with answers

1. Simple log: T1 X10→20, T2 Y5→8, commitT2, crash. Final? Under simple undo/redo assumptions, undoT1 X=10, redoT2 Y=8.
2. Which pair needs both undo and redo? Steal + no-force.
3. What must precede writing an updated page? Its relevant log records must be durable; pageLSN≤flushedLSN.
4. Does ARIES redo only committed updates? No. It repeats relevant history, then undoes losers.
5. Does fuzzy checkpoint flush all dirty pages? Not required. It records recovery state while transactions may continue.
6. LSN70, pageLSN80: apply update again? Skip that already-reflected update under the ARIES pageLSN test.
7. Why log an undo with CLR? A crash during recovery can repeat redo and resume undo without undoing an already completed compensation again.

13. Final revision and sources

Define the recovery model first. WAL protects log-before-page order. Steal creates undo needs; no-force creates redo needs. Simple examples may redo winners and undo losers. ARIES analyzes, repeats history and undoes losers. Fuzzy checkpoint is not a promise of all pages flushed; media failure needs a restore plan.

Technical references: CMU database crash recovery notes; MIT ARIES recovery lecture; Original ARIES paper. The teaching log, tables and exercises here are original examples.

Previous: concurrency | DBMS revision | Next: indexes