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 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 −
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—
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.
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
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.
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.
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.
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.
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 −
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
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.