DDBMS - Failure & Commit

DDBMS - Failure & Commit

A system of database management is susceptible to a number of failures. We will study the types of failure and commit protocols in this chapter. Failures can be classified generally into soft failures, hard failures and network failures in a distributed database system.

Soft Failure

Soft failure is the type of failure that causes the loss of the computer's volatile memory rather than persistent storage. The stored data in non-persistent storage, such as main memory, buffers, caches or records, is lost here. They are also known as system crash. The various types of soft failures are as follows −

• failure of the operating system.
• Main Crash Memory.
• Failure of Transaction or Abortion.
• Errors generated by the system such as integer overflow or divide-by-zero error.
• The failure of software support.
• Power failure.

Hard Failure

The type of failure causing data loss in the persistent or non-volatile storage like disk is a hard failure. Disk failure may cause data corruption in some disk blocks or total disk failure. The causes of a difficult failure are—

• Power failure.
• Media Faults.
• Read-write malfunction.
• The corruption of disk information.
• Read / write Disk Head Crash.

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

Network Failure

In distributed or network databases, network failures are prevalent. These include errors induced by the distributed nature of the data and data transfer over the network in the database system. As follows, the causes of network failure are

• Communication link failure.
• Congestion in networks.
• Information corruption during transfer.
• Site failures.
• Partitioning Network.

Commit Protocols

Any database system should ensure that a transaction's desirable properties are maintained even after failures. If a failure occurs during the execution of a transaction, all the changes that the transaction brings in will not be committed. It renders the database inconsistent. Commit protocols avoid using either transaction undo (rollback) or transaction redo (roll forward) in this scenario.

Commit Point

The point of time at which a decision is taken about whether to commit or end a transaction is referred to as the point of commit. The features of a commit point are as follows.

• It is a point in time when the database is consistent.
• At this point, the other transactions can be seen by the changes brought about by the database. A consistent view of the database is possible for all transactions.
• All transaction operations have been successfully performed at this point, and their results have been recorded in the transaction log.
• At this point, a transaction can be safely undone, if necessary.
• A transaction unlocks all the locks kept by it at this point.

Transaction Undo

The process of undoing all the changes that a transaction makes to a database is called transaction undo or transaction rollback. In the case of soft failure, this is often applied.

Transaction Redo

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

Transaction Log

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

Transaction log purposes −

• Help Commit protocols for commit or supporting transactions.
• To aid recovery of database after failure.

Typically, a transaction log is kept on the disk, so that soft failures do not affect it. In addition, to protect it from disk failures as well, the log is periodically backed up to an archival storage like magnetic tape.

Lists in Transaction Logs

Depending on the status of the transaction, the transaction log maintains five types of lists. This list helps the recovery manager to determine a transaction 's status. The following are the status and the corresponding lists

• A committed transaction maintained in the commit list is a transaction that has a transaction start record and a transaction commit record.
• A failed transaction, kept in the failed list, is a transaction that has a transaction start record and a transaction failed record but not a transaction abort record.
• An aborted transaction held in the abort list is a transaction that has a transaction start record and a transaction abort record.
• A before-commit transaction is a transaction that has a transaction start record and a transaction before-commit record, i.e. a transaction where all the operations have been completed but not committed, retained in the before-commit list.
• An active transaction, held in the active list, is a transaction that has a transaction start record but no before-commit, commit, abort or error records

Immediate Update and Deferred Update

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

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

In deferred update mode, the changes made to the database by the transaction are recorded in the log file when the transaction is executed. When committed, the log changes are written to the disk. On rollback, the log changes are discarded and no changes to the database are applied.