Role of check points in log based recovery?

Answer 1

Checkpoints

Problems in recovery procedure;

• Searching the entire log is time consuming

• We might unnecessarily redo transactions that have already output their updates to the database.

• Streamline recovery procedure by periodically performing

• Check pointing procedure

• Output all log records currently residing in main memory onto stable storage.

• Output all modified buffer blocks to the disk

• Write a log record onto stable storage.

Checkpoint system failure

During recovery we need to consider only the most recent transaction Ti that started before the checkpoint, and transactions that started after Ti.

Log based recovery

The log, sometimes called the trail or journal, is a history of actions executed by the DBMS. Physically, the log is a file of records stored in stable storage, which is assumed to survive crashes; this durability can be achieved by maintaining two or more copies of the log on deferent disks (perhaps in different locations), so that the chance of all copies of the log being simultaneously lost is negligibly small.

The most recent portion of the log, called the log tail, is kept in main memory and is periodically forced to stable storage. This way, log records and data records are written to disk at the same granularity (pages or sets of pages).

Every log record is given a unique id called the log sequence number (LSN). As with any record id, we can fetch a log record with one disk access given the LSN. Further, LSNs should be assigned in monotonically increasing order; this property is required for the ARIES recovery algorithm. If the log is a sequential file, in principle growing indefinitely, the LSN can simply be the address of the first byte of the log record. For recovery purposes, every page in the database contains the LSN of the most recent log record that describes a change to this page. This LSN is called the page LSN.

A log record is written for each of the following actions:

1. Updating a page: After modifying the page, an update type record (described later in this section) is appended to the log tail. The page LSN of the page is then set to the LSN of the update log record. (The page must be pinned in the buffer pool while these actions are carried out.)

2. Commit: When a transaction decides to commit, it force-writes a commit type log record containing the transaction id. That is, the log record is appended to the log, and the log tail is written to stable storage, up to and including the commit record.2 The transaction is considered to have committed at the instant that its commit log record is written to stable storage. (Some additional steps must be taken, e.g., removing the transaction's entry in the transaction table; these follow the writing of the commit log record.)

3. Abort : When a transaction is aborted, an abort type log record containing the transaction id is appended to the log, and Undo is initiated for this transaction

4. End As noted above, when a transaction is aborted or committed, some additional actions must be taken beyond writing the abort or commit log record. After all these additional steps are completed, an end type log record containing the transaction id is appended to the log.

5. Undoing an update : When a transaction is rolled back (because the transaction is aborted, or during recovery from a crash), its updates are undone. When the action described by an update log record is undone, a compensation log record, or CLR, is written.

Every log record has certain fields: prevLSN, translD, and type. The set of all log records for a given transaction is maintained as a linked list going back in time, using the prevLSN field; this list must be updated whenever a log record is added. The trasID field is the id of the transaction generating the log record, and the type field oIviously indicates the type of the log record.

Additional fields depend on the type of the log record. We have already mentioned the, additional contents of the various log record types, with the exception of the update and compensation log record types, which we describe next. Update Log Records.

The pagelD field is the page id of the modified page; the length in bytes and the offset of the change are also included. The before-image is the value of the changed bytes before the change; the after-image is the value after the change. An update log record that contains both before- and after-images can be used to redo the change and to undo it. In certain contexts, which we will not discuss further, we can recognize that the change will never be undone (or, perhaps, redone). A redo-only update log record will contain just the after-image; similarly an undo-only update record will contain just the before-image.

Log File

Contains information about all updates to database:

• Transaction records.

• Checkpoint records.

Transaction records contain:

• Transaction identifier

• Type pf log record, (transaction start, insert, update, delete, abort, commit).

• Identifier of data item affected by database action (insert, delete, and update operations).

• Before-image of data item.

• After-image of data item.

• Log management information.

A technique often used to perform recovery is the transaction log or journal

1. Records information about the progress of transactions in a log since the last

consistent state.

2. The database therefore knows the state of the database before and after each transaction.

3. Every so often database is returned to a consistent state and the log may be truncated to remove committed transactions.

4. When the database is returned to a consistent state the process is often referred to as checkpointing.