System failure recovery: After a system crash (for example, power loss) that brings the DBMS down, which recovery action is generally preferred to restore the database to a consistent, committed state?

Introduction / Context:
When a system failure occurs, the DBMS must restore the database to a consistent state that reflects all committed transactions and none of the uncommitted ones. Recovery uses logs and checkpoints to accomplish this efficiently.

Given Data / Assumptions:

• The failure is system-wide (crash), not just a single transaction error.
• Write-ahead logging is in place; the DBMS maintains redo/undo information.
• Backups and transaction logs are available.

Concept / Approach:

Recovery typically involves two phases: undo uncommitted transactions (rollback of their changes) and redo committed transactions not yet persisted at the time of the crash. The act of redoing from the log to advance the database to the last consistent, committed point-in-time is called rollforward (also known as REDO). Hence, rollforward is the preferred action to bring the database up after a crash, using the log to apply committed work since the last checkpoint/backup.

Step-by-Step Solution:

Verification / Alternative check:

Examine recovery logs: you will see analysis, undo, and redo phases; after rollforward completes, committed data is present and consistent.

Why Other Options Are Wrong:

Rollback alone would discard in-flight work but would not reapply committed operations lost due to the crash.

Switching to a duplicate database is a disaster-recovery strategy, not the standard crash-recovery path.

Reprocessing transactions is manual and error-prone; logs exist to automate redo.

Common Pitfalls:

Not archiving logs, making rollforward impossible; misunderstanding that both undo and redo phases are part of crash recovery, with rollforward crucial for restoring committed work.

Final Answer:

Rollforward