Q1. A transaction writes to a page with . The log contains the following LSNs: , , , . Which log entries will be redone if a crash occurs?
- Concept: The redo phase reapplies log records to ensure updates are on disk. An update logged with LSN is redone on a page only if .
- Analysis:
- LSN : . Not redone.
- LSN : . Not redone.
- LSN : . Redone.
- LSN : . Redone.
- Answer: Log entries with LSNs and will be redone.
Q2. Consider a transaction that made the following updates: - LSN → Page - LSN → Page - LSN → Page If crashes before committing, what will be the sequence of undo operations?
- Concept: Undo proceeds backward through the transaction’s log records.
- Analysis: is a “loser” transaction. The undo phase will process its updates in reverse order of their LSNs.
- Undo the action at LSN (Page ).
- Undo the action at LSN (Page ).
- Undo the action at LSN (Page ).
- Answer: The undo operations will be performed in the sequence corresponding to LSNs , , and .
Q3. If a system takes a checkpoint every transactions and a crash occurs after transactions, how many transactions need to be analyzed during recovery?
- Concept: The analysis phase starts from the last complete checkpoint and scans to the end of the log to identify dirty pages and transactions that were active at the time of the crash.
- Analysis: The last checkpoint would likely have been taken around the completion of transaction . The analysis phase needs to examine the log records generated since that checkpoint. This includes transactions through .
- Answer: At least transactions ( to ) need to be analyzed. Potentially more if some transactions started before were still active during the checkpoint or at the time of the crash. However, based on the interval, is the most direct answer.
Q4. A system logs the following dirty pages at a checkpoint: - Page (first modified at LSN ) - Page (first modified at LSN ) If a crash occurs at LSN , from which LSN should the redo phase start?
- Concept: The redo phase must start from the minimum (Recovery LSN, the LSN of the first log record that made the page dirty) of all pages listed in the Dirty Page Table (DPT) at the checkpoint.
- Analysis: The s are (for Page ) and (for Page ). The minimum of these is .
- Answer: The redo phase should start from LSN .
Q5. Each log record in ARIES takes bytes. If a transaction generates log records, how much space will it consume?
- Concept: Total space = Number of records × Size per record.
- Calculation: .
- Answer: It will consume bytes (or KB) of log space.
Q6. A transaction performs the following operations: 1. Writes Page at LSN . 2. Writes Page at LSN . 3. Encounters an error and rolls back to LSN . How is this handled in ARIES?
- Concept: During rollback (normal operation or recovery undo), ARIES writes Compensation Log Records (CLRs) for each undone action. CLRs are not undone themselves.
- Handling:
- initiates rollback.
- It needs to undo the operation at LSN (Write Page ).
- ARIES writes a CLR to the log. This CLR describes the undo action for LSN , restores Page to its previous state, and contains a pointer () to the LSN of the previous update by (which is related to LSN , stored in the field of the LSN record).
- The actual undo operation for Page is performed.
- Since the rollback is specified to LSN , the operation at LSN itself is not undone. The rollback process for stops after undoing LSN .
- Answer: ARIES writes a Compensation Log Record (CLR) describing the undo of the LSN update. The change to Page is physically undone. The CLR ensures this undo operation won’t be repeated and points to the next LSN to consider for undo (related to LSN ), but since the rollback target was LSN , the process stops.
Q7. A data page has . The log contains: - LSN (Update to Page ) - LSN (Update to Page ) - LSN (Update to Page ) Which entries will be redone?
- Concept: Redo applies log record to page if . This check is done for each update record encountered during the redo scan.
- Analysis: Assume Page has .
- LSN (Page ): Is ? No. This update will not be redone on Page .
- LSN (Page ): Is ? Yes. This update will be redone on Page . Page ‘s will then be set to .
- LSN (Page ): This affects Page . It will be redone if LSN . We don’t know Page ‘s , but this log record is a candidate for redo during the redo phase scan.
- Answer: LSN (Update to Page ) will definitely be redone based on the given . LSN (Update to Page ) will also be processed during redo and applied if exceeds Page ‘s at that time. LSN will not be redone for Page .
Q8. A system follows Write-Ahead Logging (WAL). If a transaction commits at LSN , what is the latest LSN that must be written to disk before committing?
- Concept: The WAL principle requires that log records describing changes (including the commit record) must be written to stable storage (disk log) before the corresponding changes (or the commit acknowledgment) are finalized.
- Analysis: The commit record itself (LSN ) finalizes the transaction. According to WAL, this record and all preceding log records for the transaction must be persistent before the commit succeeds.
- Answer: LSN must be written to the stable log on disk before the commit is considered complete.
Q9. A parent transaction spawns a nested transaction . The following LSNs are logged: - starts (LSN ) - starts (LSN ) - writes Page (LSN ) - commits (LSN ) - crashes before committing What happens during recovery?
- Concept: In many nested transaction models (like ARIES), a nested transaction’s commit is relative to its parent. If the parent aborts, the nested transaction’s effects are also rolled back, even if it logged a ‘commit’.
- Analysis: crashed, making it a loser transaction. Since is nested within , its fate is tied to . Even though logged a commit (LSN ), ‘s crash means ‘s effects must be undone.
- Recovery:
- Analysis phase identifies as a loser.
- Redo phase might reapply ‘s write (LSN ) if needed ( LSN ).
- Undo phase processes backward. It will encounter LSN (‘s write) and undo it because is a loser. A CLR will be written for this undo action.
- Answer: is identified as a loser. During the undo phase, the update made by the nested transaction at LSN will be undone, despite having a commit record (LSN ), because the parent transaction aborted.
Q10. Consider two transactions, and , with the following logs: - updates Page (LSN ) - updates Page (LSN ) - commits (LSN ) - crashes before committing What will happen during the redo phase?
- Concept: The redo phase repeats history based on the log, starting from the calculated . It reapplies updates irrespective of whether the transaction ultimately committed or aborted.
- Analysis: The redo phase scans forward.
- It encounters LSN ( update). It will redo this update on Page if .
- It encounters LSN ( update). It will redo this update on Page if .
- It encounters LSN ( commit). This marks as committed but doesn’t involve a page update redo.
- Answer: During the redo phase, the updates for both (at LSN ) and (at LSN ) will be potentially reapplied, depending on the checks for Page and Page , respectively. The final status (committed/crashed) of the transactions does not affect the redo logic itself. (The effects of the crashed transaction will be removed later during the undo phase).