The log remembers what happened, so the database can un-happen it
Every promise this unit made — atomicity, durability, safe interleaving — is worthless if a crash can quietly break them. This closing lesson explains how a write-ahead log lets the DBMS recover to a correct state no matter when the power fails.
After this lesson
You should be able to
- Classify a failure by what it destroys — transaction, system, or storage.
- Explain why the log record for a change must be written to disk before the change itself.
Not every failure destroys the same thing
A transaction failure is local — a logic error or a violated constraint aborts one transaction, while the rest of the system, and disk, remain completely fine. A system crash is more serious — a power failure or OS crash wipes volatile memory entirely, losing any transaction that was mid-flight, but the disk itself, and everything already durably written to it, survives untouched.
A disk failure is the most severe — the storage medium itself is damaged, and data written there is lost unless a separate backup exists. Recovery techniques must handle all three, but this lesson focuses on the first two, which the DBMS's own log-based mechanism directly addresses.
The write-ahead log: write down the plan before you execute it
The core idea of log-based recovery is the write-ahead logging rule: before any change is made to the actual database on disk, a log record describing that change (which transaction, which item, the old value, the new value) must first be written to disk. This ordering is not optional — it is what makes recovery possible at all.
This is exactly why: if the system crashes, the log on disk is the only surviving, trustworthy record of everything that was in progress. On restart, recovery scans the log and performs redo — reapplying the effects of every transaction that had committed but whose changes may not have reached disk yet — and undo — reversing the effects of every transaction that was still active (not yet committed) when the crash happened, using the log's old values to restore them.
<T1, start>
<T1, X, 500, 400>
<T1, commit>
<T2, start>
<T2, Y, 300, 200>
[CRASH — no <T2, commit>]
Recovery: redo T1 (committed, reapply X=400)
undo T2 (never committed, restore Y=300)Recovery when many transactions were running at once
In a real system, many transactions interleave, exactly as the earlier lessons in this unit described, so the log after a crash contains records from several transactions tangled together. Recovery must scan this shared log and correctly sort out which transactions had committed (redo them) and which had not (undo them) — this is precisely why every log record is tagged with its transaction's identifier, so recovery can group and resolve each transaction's fate independently even from one shared, interleaved log.
Checkpoints periodically record which transactions are active at a given moment, so recovery does not need to scan the entire log back to the beginning of time — only back to the most recent checkpoint. This closes the loop on everything this unit built: atomicity and durability from the first lesson, safe interleaving from the second and third, and now, the mechanism that makes all of those promises survive a crash rather than just a textbook definition.
Try it yourself
A crash happens. The log shows T1 fully committed, and T2 has a start record but no commit record. Describe exactly what recovery does for each transaction, and why.
Need a hint?
Committed means the promise was made and must be kept, even after a crash. Never committed means it was never a promise at all, and should leave no trace.
Check the worked solution
Recovery redoes T1: since T1 committed, its effects were promised to be permanent, so recovery reapplies them to guarantee durability, even though they may not have reached disk before the crash. Recovery undoes T2: since T2 never committed, none of its effects were ever promised, so recovery uses the log's old values to erase any partial changes T2 made, preserving atomicity — T2 ends up looking exactly as if it never ran.
Quick check
Why must a log record describing a change be written to disk before the change itself is written to the database?
Why this lesson exists
Syllabus mapping
Recovery System-Failure Classification, Storage, Recovery and Atomicity · Log-Based Recovery, Recovery with Concurrent Transactions
Maps to course outcome CO3.