Database System Concept 20-recovery system

When the computer system fails due to the reasons of disk, power supply, software, etc., it will cause the loss of information in the database. In addition, transactions can fail for a variety of reasons, such as breaking integrity constraints or deadlocks. An important part of the database system is the recovery mechanism, which detects the failure and restores the database to a state prior to the failure.
Once a failure occurs, the state of the database system may no longer be consistent, that is, it does not reflect the state of the real world the database is trying to preserve, and to maintain consistency, requires that each transaction must be atomic. The responsibility of the recovery mechanism is to ensure atomicity and permanence.

One, in the log-based mechanism, all updates are counted into the log and stored in the stable memory. This transaction is considered committed when the last log record of the transaction (that is, the commit log record) is output to stable storage.

The log records include the old and new values of all updated data items. When the system crashes and needs to redo the update, the new value is used and the old value is used if the transaction needs to be rolled back.

In the deferred modification mechanism, when a transaction executes, all write operations are deferred until the transaction commits, and then the system uses the information in the log that is related to the transaction in the execution of the deferred write. In the deferred modification mechanism, log records do not need to contain the old values of the updated data items.
To reduce the overhead of searching for logs and redo transactions, you can also use checkpoint technology. During the recovery phase, you simply replay all the actions that have been done in normal operation since the last completed checkpoint.

The efficient implementation of the recovery mechanism requires minimizing the number of writes to the database and to the stable memory. In the storage model on which the transaction is based, there is a log buffer, a database buffer, and a system buffer in the main memory. Log records can be stored in volatile log buffers at the beginning, and must be written to stable memory when one of the following occurs:
Before <t, commit> logging can be output to stable memory, all log records related to transaction T must have been output to stable memory.
Before a database in main memory is exported to a database in nonvolatile memory, all log records related to the data in that block must already be exported to the stable memory.

Second, in order to recover from the failure that caused the loss of data in nonvolatile memory, the contents of the whole database must be periodically dumped into stable memory (e.g. once a day). If a failure occurs that causes the physical database to be lost, use the last dump to restore the database to a previous consistent state. Once the recovery is complete, the database is then restored to the most recent consistent state using the log.

The remote backup system provides a higher degree of reliability, allowing transactions to continue even if the primary site is damaged by fire, flooding, or earthquakes. Data and log records at the primary site are continuously backed up to the remote backup site. If the primary site fails, the remote backup site performs a certain recovery action and then takes over the transaction.

Learning materials: Database System concepts, by Abraham Silberschatz, Henry F.korth, S.sudarshan

Database System Concept 20-recovery system