"Database System Concepts" 20 - Recovery System

When the computer system fails due to reasons such as disk, power supply, software, etc., it will cause the loss of database system information. In addition, transactions can fail for various reasons, such as broken integrity constraints or deadlocks. An important part of a database system is the recovery mechanism, which is responsible for detecting failures and restoring the database to the state it was in before the failure occurred. Once a failure occurs, the state of the database system may no longer be consistent, i.e. it does not reflect the real-world state the database is trying to hold, and to maintain consistency, each transaction must be atomic. The responsibility of the recovery mechanism is to ensure atomicity and durability. 1. In a log-based mechanism, all updates are logged and stored in stable storage. A transaction is considered committed when its last log record (the commit log record) is output to stable storage. Log records include the old and new values ​​of all updated data items. When the update needs to be redone after a system crash, the new value is used, and if the transaction needs to be rolled back, the old value is used. In the delayed modification mechanism, all write operations are delayed until the transaction commits when the transaction is executed. At that time, the system will use the information related to the transaction in the log to execute the delayed write. In the delayed modification mechanism, the log record need not contain the old value of the updated data item. To reduce the overhead of searching the log and redoing transactions, checkpointing techniques can also be used. During the recovery phase, simply replay all actions made in normal operation since the last completed checkpoint. An efficient implementation of the recovery mechanism requires as few writes to the database and stable storage as possible. In the storage model on which transaction processing is based, there is a log buffer, a database buffer, and a system buffer in main memory. Log records may be initially stored in a volatile log buffer and must be written to stable storage when one of the following occurs: All logs associated with transaction T before log records can be output to stable storage The record must have been output to stable storage. Before a database in main memory can be exported to a database in non-volatile storage, all log records related to the data in the block must have been exported to stable storage. Second, in order to recover from failures that cause data loss in non-volatile storage, the entire database must be periodically dumped into stable storage (eg, once a day). If a failure occurs that results in the loss of the physical database, the most recent dump is used to restore the database to some previous consistent state. Once this recovery is complete, the log is then used to restore the database to the most recent consistent state. Remote backup systems provide a higher degree of reliability, allowing transaction processing to continue even if the primary site suffers damage such as fire, flood or earthquake. Data and log records on the primary site are continuously backed up to the remote backup site. If the primary site fails, the remote backup site performs certain recovery actions and then takes over transaction processing. Learning materials: Database System Concepts, by Abraham Silberschatz, Henry F.Korth, S.Sudarshan