Questions: Write-Ahead Logging and Database Recovery

Question 1

A database crashes immediately after a transaction commits and its log record is flushed to disk, but before the data pages are written to disk. What happens during recovery?

• A. The committed data is lost — it never reached disk
• B. The REDO phase replays the log to apply the committed changes to data pages
• C. The UNDO phase rolls back the transaction since data pages were never updated
• D. Nothing is needed — the commit acknowledgment guarantees data was written to disk

Answer: (B)

This is exactly the scenario WAL is designed for. The log record was flushed before the data pages (that is the 'write-ahead' guarantee), so the REDO phase can replay the committed change and apply it to the data pages. Option A is wrong because the log is durable even though data pages are not. Option C is wrong because UNDO is for *uncommitted* transactions. Option D mistakes the commit acknowledgment — which only guarantees the log was written — for a guarantee that data pages are on disk.

Question 2

Which statement best describes the 'write-ahead' rule in WAL?

• A. Data pages must be written to disk before the transaction can commit
• B. Log records must be flushed to stable storage before the corresponding data pages are modified on disk
• C. The client must be acknowledged before any log records are written
• D. A checkpoint must be recorded before any data modification is allowed

Answer: (B)

The 'write-ahead' constraint means the log always leads the data: a log record describing a change must be durably written before the actual data page can be modified on disk. This is what makes REDO recovery possible — if a crash occurs before data pages flush, the log still has a complete record. Option A reverses the rule (data pages are intentionally allowed to lag behind). Options C and D describe no real WAL requirement.

Question 3

A WAL checkpoint serves as a backup point: if a crash occurs after the checkpoint, the database can restore to the exact state captured at checkpoint time.

• T. True
• F. False

Answer: False

Checkpoints are a recovery optimization, not backups. A checkpoint flushes dirty buffer pages to disk and records a log sequence number, so recovery only needs to replay log records *after* the checkpoint — bounding recovery time. But a checkpoint does not create a restorable snapshot; the database still requires REDO and UNDO of subsequent log records to reach a consistent state. Point-in-time restore requires separate backup mechanisms (e.g., base backups plus archived WAL logs).

Question 4

After WAL-based crash recovery completes, every transaction that had committed before the crash will have all its changes reflected in the data files.

• T. True
• F. False

Answer: True

This is precisely what the REDO phase guarantees. The REDO phase replays all log records from committed transactions that may not have been flushed to data pages before the crash. After REDO completes, every committed transaction's effects are present in the data files. The UNDO phase then removes effects of uncommitted transactions, leaving the database in a consistent state where committed = durable and uncommitted = absent.

Question 5

Why must WAL crash recovery include an UNDO phase, and what problem would occur if it were skipped?

Model answer: The buffer pool can flush dirty pages to disk at any time — even for transactions that have not yet committed. If the database crashes mid-transaction, some of its partial writes may already be in the data files. Without UNDO, those partial changes would remain, violating atomicity (the all-or-nothing guarantee). The UNDO phase reverses changes from every transaction that was in-flight at crash time, ensuring no partially-committed work survives in the data files.

This is the key subtlety of WAL: durability (REDO) is needed because committed changes may not have hit disk yet, and atomicity (UNDO) is needed because uncommitted changes may have hit disk already. Both phases are required because the buffer pool can flush pages in either direction relative to commit boundaries. A system that only did REDO would be durable but not atomic; one that only did UNDO would be atomic but not durable.