Durability and atomicity from one rule: log the change before you make it. The log record is forced to durable storage before its data page. When the machine crashes mid-transaction, recovery reads only the log — it REDOes every committed change and UNDOes every uncommitted one, reconstructing exactly the state the committed transactions left behind.
source Mohan, Haderle, Lindsay, Pirahesh & Schwarz — ARIES, ACM Trans. Database Syst. 17(1), 1992 doi:10.1145/128765.128770 Rendered, not quoted.
A tiny bank of pages A B C D, all 100 on durable disk. Transactions write pages; the log records each write as (lsn, tx, key, before, after) and marks a commit when a transaction is durably done.
Winners (committed): T1, T2. Loser (in-flight at crash): T3.
REDO replays every logged after-image in LSN order — repeat history. UNDO walks losers' records in reverse, restoring before-images. Recovery reads the log only, never trusting the crashed disk.
This is the log that guarantees ACID's A and D. ARIES's write-ahead rule — log first, then data — sits under every durable database (DB2, SQL Server, Postgres, SQLite). It is the neighbour of steal / no-force buffer management: because dirty uncommitted pages may reach disk (steal) and committed pages need not (no-force), you need both UNDO and REDO — and both come free from the one log.
Live re-check: recompute recover(disk, log) from the current run and compare, cell-for-cell, against the independently derived committed state.
Green while the WAL rule holds. When window 6 writes data before its log, this flips red the instant recovery can no longer reproduce the committed state.
Initial durable state A=100 B=100 C=100 D=100. Three transactions run interleaved:
T1 A→70, B→130 · commit
T2 C→150 · commit
T3 D→175, C→170 · no commit — crash
At crash the buffer had stolen T3's D page to disk and had not forced T2's C page. The disk is a lie; the log is the truth.
THE LOG (durable at crash):
DISK AT CRASH unreliable
RECOVERED (REDO winners+repeat, UNDO losers):
Recovered state equals the reference committed state — exactly, and verified by exhaustive comparison over all 32 possible flush-subsets.
WALL "Just flush pages when convenient and skip the log — fsync is slow." The WALL: a crash can land between the data write and any later log write. If the data hit disk with no durable log record describing it, recovery has nothing to REDO from and nothing to UNDO with. The change is orphaned — unattributable to any transaction, unrollbackable, silently corrupting the database.
"REDO alone is enough — just replay committed work."
↳ Steal means uncommitted pages reach disk; without UNDO, T3's D=175 survives forever. Both directions are mandatory.
"A committed transaction whose pages never flushed is lost."
↳ No-force: T2's C page never hit disk, yet REDO from the log restores C=150. Commit = log durable, not data durable.
"Recovery must run to completion once, or state is wrong."
↳ ARIES recovery is idempotent — crash during recovery, run it again, same result. Verified in window 7.
The disclosed planted void: force T3's D data page to disk before its log record (violate WAL), then crash before the log record is durable. The write survives; its log record does not.
The orphaned D=175 has no log record to UNDO. Recovery cannot roll it back; the recovered state diverges from the committed reference. Window 7 catches it live.