Transaction Logging — What Does the Log Store? In write-ahead logging for recovery, which record images are typically captured in the transaction log to support undo and redo operations?

Introduction / Context:
Transaction logs (redo/undo logs) are the backbone of durability and atomicity. They record changes so the DBMS can replay or roll back work to recover from crashes or user errors.

Given Data / Assumptions:

• Write-ahead logging ensures log records are persisted before data pages.
• Recovery needs enough information to redo committed changes and undo uncommitted ones.
• Different engines vary, but conceptually they store before/after states.

Concept / Approach:
To roll forward (redo), the system uses the after-image (the new values). To roll back (undo), it uses the before-image (the old values). Keeping both enables precise restoration of the database state after failure detection. Some engines optimize representation (logical redo, physical undo), but the logical concept remains: both prior and new states are captured to enable bidirectional recovery paths.

Step-by-Step Solution:
Identify the need for redo: requires after-image.Identify the need for undo: requires before-image.Conclude that both images must be available in the log or derivable from it.Select “The before and after-image of a record.”

Verification / Alternative check:
Standard ARIES-style recovery relies on log records that facilitate both undo and redo, confirming the requirement for old and new values (directly or indirectly via compensation records).

Why Other Options Are Wrong:

• Only before or only after is insufficient for full recovery capabilities.
• “Essential data” is vague and may omit necessary details.
• Schema-only logging cannot restore data changes.

Common Pitfalls:
Assuming backups alone ensure recovery; without logs, point-in-time recovery and crash consistency cannot be guaranteed.

Final Answer:
The before and after-image of a record