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?

Difficulty: Easy

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

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion