A transaction uses REDO logging to change page A from value 5 to value 8. The system writes the commit record to the log, but crashes before flushing page A to disk. What happens during recovery?
ARecovery rolls back the transaction because the page was never written to disk before the crash
BRecovery replays the redo log entry forward, writing value 8 to page A to restore the committed state
CRecovery scans backward and restores A to value 5 using the old value stored in the log
DRecovery cannot restore this transaction because the page was not on disk at crash time
Redo logging records the *new* value (8). Recovery's job after a commit is to replay the log forward, applying all new values to bring the database up to the committed state — regardless of whether the pages were on disk at crash time. This is the defining rule of redo logging: pages may not be written to disk until after commit, so recovery knows that any committed transaction needs its changes applied. Option C describes undo logging (old values, backward scan), which is the opposite approach.
Question 2 Multiple Choice
During ARIES recovery after a crash, the analysis pass identifies two transactions: T1 (committed, with some dirty pages flushed to disk) and T2 (uncommitted, also with dirty pages flushed). In the redo pass, which logged changes are replayed?
AOnly T1's changes — T2 was uncommitted and should never be redone
BOnly T2's changes — T2's pages on disk are wrong and must be overwritten first
CBoth T1's and T2's logged changes are redone to restore the exact pre-crash disk state; then the undo pass rolls back T2
DNeither — ARIES always starts recovery from a clean checkpoint and redoes nothing before the checkpoint
ARIES's key insight is to separate physical and transactional recovery into two phases. The redo pass brings the database to the exact state it was in at the moment of crash — including uncommitted changes that had been flushed to disk. Only after this physical restoration does the undo pass enforce transactional consistency by rolling back uncommitted transactions. Skipping T2 in the redo pass would leave the disk in a mixed state that makes the undo pass impossible to execute correctly. 'Redo everything, then undo losers' is the phrase to remember.
Question 3 True / False
Undo logging requires all dirty pages to be written to disk *before* a transaction commits, while redo logging requires that dirty pages *not* be written to disk until after the commit record is in the log.
TTrue
FFalse
Answer: True
This is the defining constraint of each approach. Undo logging must write pages before commit because recovery scans backward and needs the old values to be superseded by what's actually on disk — if the crash happened before commit, rollback restores old values. Redo logging must hold pages until after commit because recovery replays the log forward — if the crash happened before commit, no committed state exists to replay, so no rollback is needed. The two rules are exact opposites, reflecting the opposite directions of recovery.
Question 4 True / False
In ARIES, the redo pass primarily replays changes from committed transactions, since replaying uncommitted changes would violate transaction isolation.
TTrue
FFalse
Answer: False
This is the most common misconception about ARIES. The redo pass replays ALL logged changes — committed and uncommitted — to bring the physical disk state to exactly what it was at the moment of the crash. ARIES's buffer manager may flush uncommitted dirty pages to disk at any time, so after a crash the disk may contain a mix of committed and uncommitted work. The redo pass restores this exact state; the undo pass then cleanly rolls back uncommitted transactions. Isolation is enforced by the undo pass, not by filtering the redo pass.
Question 5 Short Answer
Why does ARIES redo *all* changes — including those from uncommitted transactions — before undoing anything, rather than simply replaying only committed work and skipping uncommitted changes?
Think about your answer, then reveal below.
Model answer: Because ARIES allows the buffer manager to flush dirty pages to disk at any time — before or after commit. After a crash, the disk may contain partial writes from uncommitted transactions that were flushed. The redo pass must replay all logged changes to bring the disk to the exact pre-crash state, because only from that exact state can the undo pass cleanly reverse uncommitted work. If the redo pass skipped uncommitted changes, the disk would be in a mixed, inconsistent state where the undo pass could not determine what was actually written and what was not.
The elegance of ARIES is that it separates two concerns: 'make the physical state consistent with the log' (redo everything) and 'enforce transactional atomicity' (undo uncommitted work). Conflating these — trying to filter the redo pass for committed-only changes — would require the recovery algorithm to know which pages correspond to which transactions before it has restored the log state, creating a circular dependency.