Distributed DBMS - Failure & Commit

A database management system is susceptible to a number of failures. In this chapter we will study the failure types and commit protocols. In a distributed database system, failures can be broadly categorized into soft failures, hard failures and network failures.

Soft Failure

Soft failure is the type of failure that causes the loss in volatile memory of the computer and not in the persistent storage. Here, the information stored in the non-persistent storage pke main memory, buffers, caches or registers, is lost. They are also known as system crash. The various types of soft failures are as follows −

Operating system failure.

Main memory crash.

Transaction failure or abortion.

System generated error pke integer overflow or spanide-by-zero error.

Failure of supporting software.

Power failure.

Hard Failure

A hard failure is the type of failure that causes loss of data in the persistent or non-volatile storage pke disk. Disk failure may cause corruption of data in some disk blocks or failure of the total disk. The causes of a hard failure are −

Power failure.

Faults in media.

Read-write malfunction.

Corruption of information on the disk.

Read/write head crash of disk.

Recovery from disk failures can be short, if there is a new, formatted, and ready-to-use disk on reserve. Otherwise, duration includes the time it takes to get a purchase order, buy the disk, and prepare it.

Network Failure

Network failures are prevalent in distributed or network databases. These comprises of the errors induced in the database system due to the distributed nature of the data and transferring data over the network. The causes of network failure are as follows −

Communication pnk failure.

Network congestion.

Information corruption during transfer.

Site failures.

Network partitioning.

Commit Protocols

Any database system should guarantee that the desirable properties of a transaction are maintained even after failures. If a failure occurs during the execution of a transaction, it may happen that all the changes brought about by the transaction are not committed. This makes the database inconsistent. Commit protocols prevent this scenario using either transaction undo (rollback) or transaction redo (roll forward).

Commit Point

The point of time at which the decision is made whether to commit or abort a transaction, is known as commit point. Following are the properties of a commit point.

It is a point of time when the database is consistent.

At this point, the modifications brought about by the database can be seen by the other transactions. All transactions can have a consistent view of the database.

At this point, all the operations of transaction have been successfully executed and their effects have been recorded in transaction log.

At this point, a transaction can be safely undone, if required.

At this point, a transaction releases all the locks held by it.

Transaction Undo

The process of undoing all the changes made to a database by a transaction is called transaction undo or transaction rollback. This is mostly appped in case of soft failure.

Transaction Redo

The process of reapplying the changes made to a database by a transaction is called transaction redo or transaction roll forward. This is mostly appped for recovery from a hard failure.

Transaction Log

A transaction log is a sequential file that keeps track of transaction operations on database items. As the log is sequential in nature, it is processed sequentially either from the beginning or from the end.

Purposes of a transaction log −

To support commit protocols to commit or support transactions.

To aid database recovery after failure.

A transaction log is usually kept on the disk, so that it is not affected by soft failures. Additionally, the log is periodically backed up to an archival storage pke magnetic tape to protect it from disk failures as well.

Lists in Transaction Logs

The transaction log maintains five types of psts depending upon the status of the transaction. This pst aids the recovery manager to ascertain the status of a transaction. The status and the corresponding psts are as follows −

A transaction that has a transaction start record and a transaction commit record, is a committed transaction – maintained in commit pst.

A transaction that has a transaction start record and a transaction failed record but not a transaction abort record, is a failed transaction – maintained in failed pst.

A transaction that has a transaction start record and a transaction abort record is an aborted transaction – maintained in abort pst.

A transaction that has a transaction start record and a transaction before-commit record is a before-commit transaction, i.e. a transaction where all the operations have been executed but not committed – maintained in before-commit pst.

A transaction that has a transaction start record but no records of before-commit, commit, abort or failed, is an active transaction – maintained in active pst.

Immediate Update and Deferred Update

Immediate Update and Deferred Update are two methods for maintaining transaction logs.

In immediate update mode, when a transaction executes, the updates made by the transaction are written directly onto the disk. The old values and the updates values are written onto the log before writing to the database in disk. On commit, the changes made to the disk are made permanent. On rollback, changes made by the transaction in the database are discarded and the old values are restored into the database from the old values stored in the log.

In deferred update mode, when a transaction executes, the updates made to the database by the transaction are recorded in the log file. On commit, the changes in the log are written onto the disk. On rollback, the changes in the log are discarded and no changes are appped to the database.