Recovery & the Write-Ahead Log

A write-ahead log records changes before the data is updated, making commits fast and durable — and on restart, redo replays committed work while undo rolls back uncommitted work.

Module 6 promised durability: once COMMIT returns, a crash can't undo your change.

But writing to a table means finding the right block on a slow disk. If the database did that before every commit, commits would crawl.

So how is it both fast and crash-proof?

Why & what

By writing somewhere cheaper first.

A write-ahead log (WAL) records what a transaction is about to change, and that log entry is written to disk before the actual data is. If a crash happens, the log is used to reconstruct the correct state.

The log is fast to write because it's sequential — appended to the end of a file — while updating table blocks means jumping around the disk.

How it works

Aisha's fee payment again: 12,000 → 0.

Write the log entry first. "Transaction 7 changed Student 101 fees from 12000 to 0." Small, sequential, fast.
Return the COMMIT. Once the log is safely on disk, the transaction is durable. The user is told it succeeded.
Update the real table block later. The database does this at its leisure, batching writes efficiently. This is why commits feel instant.
Now crash — and restart. The database reads the log and does two passes: oREDO — the transaction committed but its data block was never written. Replay it. Durability preserved. oUNDO — the transaction never committed, but its data block was already written. Roll it back. Atomicity preserved.
See what this means. ACID's A and D from Module 6 aren't abstract promises. They're implemented by this log.

Pause here. Why is writing the log faster than writing the data block, when both go to the same disk?

The log is appended sequentially to the end of one file, so the disk writes in a straight line. Table blocks are scattered, so writing them means seeking around.

Recovery & the Write-Ahead Log — figure 1

Notice: the log is what makes the D and the A in ACID actually work.

Common confusion

"Write-ahead" confuses people. It means the log is written ahead of the data, not that anything is written ahead of time. Log first, data after. That ordering is the entire guarantee.

Second: people assume COMMIT waits for the data to be saved. It doesn't — it waits for the log entry to be saved. The data catches up afterwards. That's the whole performance trick.

Interview angle

"What is a write-ahead log?" — A record of intended changes written to disk before the data itself, used to recover after a crash. Say it's sequential and therefore fast.
"What are redo and undo?" — Redo replays committed transactions whose data never landed; undo rolls back uncommitted ones whose data did.
"How does a database make COMMIT fast and still durable?" — It only waits for the log write, not the data write.

Recap

A write-ahead log records changes before the data is updated, making commits fast and durable — and on restart, redo replays committed work while undo rolls back uncommitted work.

DBMS · Module 8 — Query Processing & Recovery

Recovery & the Write-Ahead Log

A write-ahead log records changes before the data is updated, making commits fast and durable — and on restart, redo replays committed work while undo rolls back uncommitted work.

Module 6 promised durability: once COMMIT returns, a crash can't undo your change.

But writing to a table means finding the right block on a slow disk. If the database did that before every commit, commits would crawl.

So how is it both fast and crash-proof?

Why & what

By writing somewhere cheaper first.

The log is fast to write because it's sequential — appended to the end of a file — while updating table blocks means jumping around the disk.

How it works

Aisha's fee payment again: 12,000 → 0.

Write the log entry first. "Transaction 7 changed Student 101 fees from 12000 to 0." Small, sequential, fast.
Return the COMMIT. Once the log is safely on disk, the transaction is durable. The user is told it succeeded.
Update the real table block later. The database does this at its leisure, batching writes efficiently. This is why commits feel instant.
Now crash — and restart. The database reads the log and does two passes: oREDO — the transaction committed but its data block was never written. Replay it. Durability preserved. oUNDO — the transaction never committed, but its data block was already written. Roll it back. Atomicity preserved.
See what this means. ACID's A and D from Module 6 aren't abstract promises. They're implemented by this log.

Pause here. Why is writing the log faster than writing the data block, when both go to the same disk?

The log is appended sequentially to the end of one file, so the disk writes in a straight line. Table blocks are scattered, so writing them means seeking around.

Recovery & the Write-Ahead Log — figure 1

Notice: the log is what makes the D and the A in ACID actually work.

Common confusion

"Write-ahead" confuses people. It means the log is written ahead of the data, not that anything is written ahead of time. Log first, data after. That ordering is the entire guarantee.

Second: people assume COMMIT waits for the data to be saved. It doesn't — it waits for the log entry to be saved. The data catches up afterwards. That's the whole performance trick.

Interview angle

"What is a write-ahead log?" — A record of intended changes written to disk before the data itself, used to recover after a crash. Say it's sequential and therefore fast.
"What are redo and undo?" — Redo replays committed transactions whose data never landed; undo rolls back uncommitted ones whose data did.
"How does a database make COMMIT fast and still durable?" — It only waits for the log write, not the data write.

Recap

A write-ahead log records changes before the data is updated, making commits fast and durable — and on restart, redo replays committed work while undo rolls back uncommitted work.