Database recovery questions look theoretical until an exam gives you a log, a checkpoint, and a crash. Then definitions are not enough: you must decide which transactions to undo, which to redo, and what values remain. A ten-record log, one checkpoint and one crash answer all three: T3 is undone, T2 is redone, and A, B and C settle at 80, 250 and 300.
What recovery protects: failures and the ACID promise
Recovery preserves two ACID guarantees. Atomicity means a half-finished transaction leaves no effect. Durability means a committed transaction survives a crash. For the foundation, revise transactions and concurrency control in DBMS.
The failure determines what recovery can use:
Transaction failure: a debit-credit transfer violates a negative-balance check, so it must abort.
System crash: power loss clears database buffers in RAM, while disk storage remains intact.
Media failure: a disk block holding the accounts table is corrupted. A log alone is insufficient here, so recovery needs a backup or mirrored copy.
Keep one mental model: a database page may exist in a volatile buffer and on non-volatile disk. Recovery controls when changes reach disk and what is recorded first, allowing repair in either direction.
The recovery log and write-ahead logging
A log stores the history needed to reverse or repeat updates. Four record forms carry it:
<T start>marks the beginning of transaction T.<T, X, old_value, new_value>records an update to item X.<T commit>records successful completion.<T abort>records rollback.
The old value supports undo. The new value supports redo.
Write-ahead logging, or WAL, has two ordering rules. An update's log record must reach stable storage before its data page is written to disk. All transaction records, including commit, must also be stable before commit is acknowledged. Otherwise a data page could reach disk without a durable old value for undo.
Map the buffer policies directly to recovery work. Steal permits a dirty-page flush before commit, so it requires undo. No-steal forbids that. Force flushes all changed pages at commit, avoiding redo. No-force does not, so it requires redo. Practical systems commonly combine steal with no-force and need both operations.
Deferred and immediate modification
Under deferred modification, updates stay in the log and local workspace until commit. An uncommitted transaction cannot dirty the disk, so recovery is redo-only.
Under immediate modification, an update can reach the buffer, and possibly disk, before commit. Recovery may need undo for uncommitted transactions and redo for committed ones.
Use the same numbers under both policies. Let A initially be 500, and let T1 calculate A := A - 50, giving 500 - 50 = 450. Suppose the crash occurs before <T1 commit> is written.
With deferred modification, disk still holds A = 500. Recovery does nothing.
With immediate modification, disk may hold A = 450. Recovery reads
<T1, A, 500, 450>and restores the old value, so450 + 50 = 500.
Disk timing changes the recovery action.
Checkpoints and a fully worked crash example
Without a checkpoint, recovery might scan the log from its beginning. A <checkpoint {active transactions}> record, combined here with a dirty-page flush, bounds that scan.
Assume immediate modification with undo/redo recovery. Initially, disk contains A = 100, B = 200, and C = 300. At the crash, the log is:
Record | Log entry |
|---|---|
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
At record 6, only T2 is active and all dirty pages are flushed. Disk holds A = 80 and B = 250. The crash follows record 10.
Now recover step by step:
Find the checkpoint and classify transactions. T2 was active at the checkpoint and committed later, so the redo list is
{T2}. T3 started later and has no commit record, so the undo list is{T3}. T1 committed before the checkpoint, and its A = 80 was flushed, so T1 needs no action.Undo T3 in reverse log order. Record 10 changed A from 80 to 60, so restore A to 80. Record 8 changed C from 300 to 350, so restore C to 300. Append
<T3 abort>to the log.Redo T2 in forward log order. Record 4 sets B from 200 to 250. Reapplying B = 250 is safe even if that value is already on disk.
Read the final state. A = 80, B = 250, and C = 300.
Shadow paging and where ARIES fits
Shadow paging keeps a current page table and an unchanged shadow page table. Updates create new pages through copy-on-write and alter only the current table. Commit atomically switches the root pointer to the current table. After a crash, the system discards the unfinished current table and uses the consistent shadow, so crash recovery needs no log.
Logs remain practical because shadow paging can fragment data, separate shadow tables make concurrency difficult, and commit-time page-table switching can be costly.
ARIES refines undo/redo logging for industrial systems. It repeats history by redoing actions since the last checkpoint, including those later undone. Page log sequence numbers track reflected updates, while compensation log records make undo safe across another crash. GATE usually stops here, while product-company interviews may probe further.
Database recovery traps that cost marks
Undoing in forward order: if one transaction writes the same item twice, forward undo can leave an intermediate value. Undo backward. Redo forward.
Redoing T1: T1 committed before this checkpoint and its update was flushed. It is not among the transactions that must be redone.
Treating
<checkpoint {T2}>as proof that T2 is safe: the active list means T2 still needs a decision. Its later commit places it in redo. Without that commit, it would need undo.Mixing the buffer-policy pairs: steal creates the need for undo. No-force creates the need for redo.
How GATE and interviews test database recovery
The Databases section of the official GATE 2026 CS syllabus lists “Transactions and concurrency control.” Recovery is tested under that topic; it is not named separately in the syllabus. Confirm the current syllabus and exam structure on the official GATE website of the conducting institute. Do not infer a fixed marks weightage from the topic's placement in the syllabus.
A recurring GATE question hands you a checkpointed crash log and asks for the undo and redo sets, or for the final value of one data item. Conceptual questions test WAL ordering and the steal/force matrix. Interviews ask about mid-transaction crashes and logging before page writes.
The DBMS transaction MCQs cover ACID and locking. Then replay this example without the checkpoint. T1 joins the redo list and sets A to 80. After hand practice, use the GATE Test Series - Mocks & Topic-wise Tests to solve recovery questions inside full papers.
The short version and next step
Data pages can exist in volatile buffers and on non-volatile disk.
WAL means the relevant log record reaches stable storage before the changed data page.
Deferred modification needs redo only. Immediate modification can need both undo and redo.
A checkpoint bounds recovery and helps determine the transaction lists.
Undo in reverse log order and redo in forward log order.
Recovery is one connected part of DBMS, not an isolated definition. For the subject in sequence from the ER model through transactions, concurrency, and recovery, continue with GATE Guidance by Sanchit Sir. Use the CS Fundamentals hub for other subject deep-dives.
