Database recovery concepts: Does backward recovery (undo/rollback) reverse changes made by transactions that abort or terminate abnormally?

Introduction / Context:Recovery ensures database consistency after failures. Backward recovery (undo/rollback) and forward recovery (redo) are core techniques used by transactional DBMSs to maintain the ACID properties.

Given Data / Assumptions:

• Transactions may abort due to errors, deadlocks, or system crashes.
• DBMSs maintain a write-ahead log (transaction log) capturing before-images and after-images.
• Goal: leave the database in a consistent state.

Concept / Approach:Backward recovery undoes the effects of incomplete or aborted transactions by restoring affected data items to their before-image values. Conversely, forward recovery reapplies committed changes after a crash. Together, these processes ensure that all committed work persists and all uncommitted work is removed.

Step-by-Step Solution:Detect abnormal termination or identify a transaction marked for rollback.Locate log records for the transaction, reading them in reverse order.For each operation, restore the before-image to the database.Mark the transaction as rolled back and release its locks.

Verification / Alternative check:Perform a simulated failure during an update and inspect the database after recovery. Only committed transactions should remain; uncommitted changes are undone.

Why Other Options Are Wrong:“Only for read-only” is nonsensical since read-only transactions make no changes. “Only with full backup restore” confuses crash recovery with media recovery.

Common Pitfalls:Misconfiguring logging (e.g., turning off WAL) which prevents reliable recovery; misunderstanding lock release order during rollback leading to anomalies in application behavior.

Final Answer:Correct