Transaction control: does ROLLBACK WORK instruct SQL to “empty the log file,” or does it simply undo uncommitted changes in the current transaction?

Introduction / Context:
ROLLBACK WORK (or simply ROLLBACK) is fundamental in transactional SQL. Misunderstanding what it does can put data integrity at risk. The statement claims that ROLLBACK “asks SQL to empty the log file,” which is not what rollback does.

Given Data / Assumptions:

• The log (write-ahead log, transaction log, redo/undo) is an internal engine structure for durability and recovery.
• ROLLBACK reverts uncommitted changes in the active transaction.
• DBMS engines manage log truncation/archiving independently of a user’s rollback.

Concept / Approach:
A rollback walks back uncommitted changes so the database returns to the last consistent state (the start of the transaction or a SAVEPOINT). It does not perform log maintenance. Log space management (checkpointing, truncation, archiving) is handled by the engine based on recovery settings, not by the ROLLBACK command itself.

Step-by-Step Solution:

Verification / Alternative check:
Inspect log file growth and retention policies; they are governed by checkpoints, backups, and engine settings, independent of a single rollback.

Why Other Options Are Wrong:

• Correct: Would misstate rollback’s purpose.
• Isolation level, savepoints, or DDL caveats do not turn rollback into a log-emptying command.

Common Pitfalls:
Confusing engine recovery mechanics with user transaction control; assuming rollback reclaims disk immediately.

Final Answer:
Incorrect