Database Basics
When updating data, many DBMSs record the changes in a log (journal) and write that log to nonvolatile storage before the database itself (WAL: write-ahead logging). What is the main reason for this approach?
- AEven if a failure occurs, the log can be used to redo committed updates and undo uncommitted ones, restoring a correct state
- BWriting the log first makes the database itself smaller
- CThe log can be used as an index for searches by SELECT statements
Show answer and explanation
Answer: A. Even if a failure occurs, the log can be used to redo committed updates and undo uncommitted ones, restoring a correct state
For performance, database pages are updated in buffers in memory and written to storage some time later. So at the moment of a failure, storage may contain a mix of committed updates that have not yet been written and uncommitted updates that have. If the before and after values of each update are recorded in a log and the log is written before the database itself, then after a failure the log can be used to redo committed updates (rollforward, REDO) and undo uncommitted ones (rollback, UNDO), restoring a correct state. A commit can be considered complete as soon as the transaction's commit record is written to the log, so database pages need not be written immediately every time, which preserves performance. This mechanism underpins the atomicity and durability of the ACID properties.
- A. Correct. Writing the log first makes it possible to restore a correct state after a failure with REDO and UNDO.
- B. The log is recorded separately from the database and does not make the database smaller.
- C. The log is a record for recovering from failures and is not used as an index for searches.