Transaction logging: Does a database transaction log record before-images and after-images for rows modified by transactions (supporting undo and redo)?

Introduction / Context:
Transaction logs (also called write-ahead logs or journals) are central to ACID properties. They capture enough information about each change to support recovery, rollbacks, and replication. Conceptually, they store the “before” state (to undo) and the “after” state (to redo) of modifications.

Given Data / Assumptions:

• The DBMS writes log records before applying data pages (write-ahead logging).
• Each logical change has sufficient detail to invert (undo) or replay (redo) it.
• Implementation specifics differ, but the effect is equivalent to before/after images.

Concept / Approach:
On crash recovery, the DBMS scans the log, redoes committed work not yet on disk and undoes uncommitted updates to ensure consistency. Point-in-time recovery and replication also leverage these records. Whether the system stores physical before/after bytes or logical operations, the semantics allow reconstructing prior and new states.

Step-by-Step Solution:
Begin a transaction; DBMS logs intended changes (WAL).Apply changes to in-memory pages; flush log to stable storage on commit.On crash, redo committed but unflushed changes using after-images.Undo in-flight transactions to remove partial effects using before-images.Bring database to a consistent, committed state.

Verification / Alternative check:
Demonstrate a forced crash after commit but before data page flush; recovery uses redo to make data durable, proving the role of after-images in practice.

Why Other Options Are Wrong:
Incorrect: contradicts core logging semantics.Only for inserts or in-memory DBs: all durable ACID systems implement equivalent logging.

Common Pitfalls:
Misconfiguring log retention, placing logs and data on the same failing media, or skipping validated backups that align with log chain continuity.

Final Answer:
Correct