Database recovery basics: Does the restore/rerun technique reprocess the day’s transactions up to the point of failure after restoring the last good backup?
-
ACorrect
-
BIncorrect
-
COnly for distributed databases
-
DUsed only when no logs exist
Answer
Correct Answer: Correct
Explanation
Introduction / Context:Recovery strategies determine how quickly and accurately a database returns to a consistent state after a crash or corruption. The restore/rerun technique is a classic approach for systems that process batches of transactions, especially where the unit of work is a day’s workload.
Given Data / Assumptions:
- You have a reliable, recent full backup taken before the failure.
- The system archived or captured the day’s transactions in an ordered form (logs, journal, or batch input files).
- Transactions are deterministic and can be re-applied safely in the same sequence.
Concept / Approach:Restore/rerun proceeds in two phases: first, restore the last known good backup to return the database to a consistent baseline; second, rerun (replay) the day’s transactions from the beginning of the period up to the failure. This recovers committed work while avoiding lost updates. It is conceptually similar to roll-forward recovery using archive logs but is often described in batch contexts.
Step-by-Step Solution:Restore full backup to a clean environment.Validate integrity and baseline consistency.Apply transactions in recorded order up to the failure time.Reconcile any partially processed batches based on checkpoints.Reopen the system and resume normal processing.
Verification / Alternative check:Compare ending balances or control totals before failure to the post-recovery state. If they match expected audit totals through the last good commit, restore/rerun succeeded.
Why Other Options Are Wrong:Incorrect: misstates the standard recovery flow.Only for distributed DBs: the approach is topology-agnostic.Used only when no logs exist: logs or batch journals are typically required for rerun.
Common Pitfalls:Missing or corrupt input journals, non-idempotent transaction logic, unreconciled time-of-failure edge cases, and inadequate audit trails.
Final Answer:Correct