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