Crash recovery

Click here to download this note into your device.

Transaction is a collection of actions that transform a database from a consistent state to another consistent state; during the execution the database might be inconsistent.

Properties of a transaction

The ACID properties of a transaction are:

Atomicity: a transaction is treated as a single/atomic unit of operation and is either executed completely or not at all.

Consistency: a transaction preserves DB consistency. It transforms DB from its consistent state to consistent state.

Isolation: Execution of one transaction is isolated from that of other transactions.

Durability: if a transaction commits, its effect persists. If a transaction has been reported back to the user as complete, the resulting changes to the database survive subsequent hardware and software failures.

A transaction can be interrupted before running to completion for variety of reasons e.g. system crashes, disk failure, logical errors, system errors, etc. A DBMS must ensure that the changes made by such incomplete transactions are removed from the DB. For example, if the DBMS is in the middle of transferring money from account A to account B, and has debited the first account but not yet credited the second account when the crash occurs, the money debited from account A must be restored when the system comes back up after the crash.

The recovery manager of a DBMS is responsible for ensuring atomicity by undoing (rolling back) the actions of transactions that do not commit and durability by making sure that all actions of committed transactions survive system crashes and media failures i.e. corrupt disk.

The aim of crash recovery is to restore the database to the most recent consistent state which existed prior to the failure/crash.

Introduction to ARIES

The ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) is a database recovery algorithm and has three phases:

Analysis phase: It scans the log (history of executions by the DBMS) forward (from the most recent checkpoint) to identify all active transactions and dirty pages in the buffer pool at the time of the crash.

Redo phase: This phase returns the database to the state at the time the DB crash occurred. Database history is repeated to reconstruct state at crash.

Undo phase: When the system restarts after the crash, the list of active transactions (uncommitted at the time database crashed) identified in phase 1 is rolled back (reversed) individually and restores the database to the consistent state that existed before the start of transaction.

Other recovery related data structure

In addition to the log, the following two tables contain important recovery related information:

Transaction table: this table contains one entry for each active transaction. The entry contains (among other things) the transaction id, status, etc. The status can be that it is in progress, committed or is aborted.

Dirty page table: contains one entry for each dirty page in the buffer pool, i.e. pages with changes that are not yet reflected on disk.

Write Ahead Logging (WAL) protocol

WAL is one of the principles behind ARIES recovery algorithm. In a system using WAL, all modifications to the database object  are first recorded in the log, the record in the log must be written to stable storage before the change to the database object is written to disk( before they are applied on the database).

The purpose of this can be illustrated by an example. Imagine a program that is in the middle of performing some operation when the machine it is running on loses power. Upon restart, that program might well need to know whether the operation it was performing, succeeded or failed. If a write-ahead-log was used, the program could check this log and compare what it was supposed to be doing when it unexpectedly lost power to what was actually done. On the basis of this comparison, the program could decide to undo what it had started, complete what it had started, or keep things as they are.

Check pointing

Keeping and maintaining the logs in real time may fill out all the memory space available in the system. As time passes log file may be too big to be handled at all. Checkpoint is a mechanism where all the previous logs are removed from the system and stored permanently in storage disk. Checkpoint declares a point before which the DBMS was in a consistent state and all transactions were committed. Periodic check pointing can reduce the time needed to recover from a crash.

Lock: A mechanism used to control access to a database objects.

Shared lock on an object can be held by two transactions at the same time. If a transaction needs to read a database object, a shared lock is required.

Exclusive lock on an object ensures that no other transaction hold any lock on this object. If a transaction needs to write (modify or change) a database object, an exclusive lock is required.

Media recovery: this is the process of restoring the entire disk files/folders after a crash. Disk failure can occur as a result of formation of bad sectors, disk head crash, or any other failures which destroys all or parts of disk storage.

Click here to download this note in your device