6/6/23, 1:16 PM Distributed DBMS - Failure & Commit

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 like 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 like integer overflow or divide-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
like 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.

[Link] 1/4
6/6/23, 1:16 PM Distributed DBMS - Failure & Commit

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 link 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.

[Link] 2/4
6/6/23, 1:16 PM Distributed DBMS - Failure & Commit

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 applied 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 applied 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 like magnetic tape to protect it from disk
failures as well.

Lists in Transaction Logs

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

A transaction that has a transaction start record and a transaction commit record, is a
committed transaction – maintained in commit list.
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 list.

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

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 list.

[Link] 3/4
6/6/23, 1:16 PM Distributed DBMS - Failure & Commit

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 list.

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 applied to the database.

[Link] 4/4