A database server loses power and restarts. When it comes back online, every transaction that was committed just before the outage is present, and every transaction that was still in progress has been rolled back. Which mechanism makes this recovery possible?
Select an answer to reveal the explanation.
Short Explanation
Here's the rule that saves you: write it in the log first, then touch the data. After a crash, the database reads that log like a diary, replays what was committed and tears up what wasn't. Backups and snapshots can't do this, because they'd lose everything since they were taken.
Full Explanation
Transaction logging, usually implemented as write-ahead logging, requires that a description of each change be written durably to the log before the corresponding data pages are written to disk, and a commit is acknowledged only when its log records are safe. After a crash, the data files may contain some changes from uncommitted transactions and lack some changes from committed ones. During restart recovery, the engine reads the log, redoes committed changes that never reached the data files and undoes changes from transactions that never committed, leaving a consistent database that matches the durability and atomicity guarantees of ACID. A nightly full backup would roll the database back a full day and lose every commit since, which contradicts the scenario. An hourly snapshot would likewise lose up to an hour of committed work and cannot distinguish committed from in-progress transactions. Index rebuilds reorganize index structures and do not reconstruct row data or transaction outcomes; they play no role in crash recovery. Exam caveat: transaction logging also underpins point-in-time restore, log shipping and many replication methods, so protecting the log is part of fault tolerance. Operational check: confirm that the log resides on durable storage, review the startup recovery messages after any unclean shutdown and verify that integrity checks pass afterward.