Database log
Encyclopedia : D : DA : DAT : Database log
In in the field of databases in computer science, a database log (also transaction log or binary log) is a history of actions executed by a database management system to guarantee ACID properties over crashes or hardware failures. Physically, a log is a file of records stored in stable storage.
If, after a start, the database is found in an inconsistent state or not been shut down properly, the database management system reviews the database logs for uncommitted transactions and rolls back the changes made by these transactions, in order to provide atomicity and durability of transactions.
This term is not to be confused with normal logs which are generally intended to be verbose and human-readable.
Anatomy of a general database log
A database log record is made up of
- Log Sequence Number: A unique id for a log record. With LSNs, logs can be recovered in constant time. Most logs' LSNs are assigned in monotonically increasing order, which is useful in recovery algorithms, like ARIES.
- Prev LSN: A link to the last log record. This implies database logs are constructed in linked list form.
- Transaction ID number: A reference to the database transaction generating the log record.
- Type: Describes the type of database log record.
Types of database log records
All log records include the general log attributes above, and also other attributes depending on their type (which is recorded in the Type attribute, as above).
- Update Log Record notes an update (change) to the database. It includes this extra information:
- *PageID: A reference to the Page ID of the modified page.
- *Length and Offset: Length in bytes and offset of the page are usually included.
- *Before and After Images: Includes the value of the bytes of page before and after the page change. Some databases may have logs which include one or both images.
- Compensation Log Record notes the rollback of a particular change to the database. Each correspond with exactly one other Update Log Record (although the corresponding update log record is not typically stored in the Compensation Log Record). It includes this extra information:
- *undoNextLSN: This field contains the LSN of the next log record that is to be undone for transaction that wrote the last Update Log.
- Commit Record notes a decision to commit a transaction.
- Abort Record notes a decision to abort and hence rollback a transaction.
- Checkpoint Record notes that a checkpoint has been made. These are used to speed up recovery. They record information that eliminates the need to read a long way into the log's past. This varies according to checkpoint algorithm. If all dirty pages are flushed while creating the checkpoint (as in PostgreSQL), it might contain:
- *redoLSN: This is a reference to the first log record that corresponds to a dirty page. i.e. the first update that wasn't flushed at checkpoint time. This is where redo must begin on recovery.
- *undoLSN: This is a reference to the oldest log record of the oldest in-progress transaction. This is the oldest log record needed to undo all in-progress transactions.
- Completion Record notes that all work has been done for this particular transaction. (It has been fully committed or aborted)
Tables
These tables are maintained in memory, and can be efficiently reconstructed (if not exactly, to an equivalent state) from the log and the database:
- Transaction Table: The table contains one entry for each active transaction. This includes Transaction ID and lastLSN, where lastLSN describes the LSN of the most recent log record for the transaction.
- Dirty Page Table: The table contains one entry for each dirty page that haven't been written to disk. The entry contains recLSN, where recLSN is the LSN of the first log record that caused the page to be dirty.
From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.