Database review 7 -- restore

Database review 7 -- restore
Database review CH14 recovery 13.1 recovery concept

Database SystemRestoreIt refers to the behavior that restores the database from an inconsistent state after a certain "failure" to a normal consistent state. The basis for recovery isRedundancy(Physical redundancy, non-logical)

These failures include:

Transaction failure: including logical errors (the transaction cannot be executed if it does not meet certain conditions) and system errors (DBMS forces to terminate the transaction, such as a deadlock in the transaction) system crash: power failure, physical hardware damage, software system (such as OS) Crash, this chapter assumes that the system crash does not change non-Easy loss storage disk failure: disk storage error, this chapter assumes that you can use the check and monitoring disk failure

In general, the recovery policy is divided into two steps:

When a normal transaction is processed, enough additional information is recorded for the recovery failure when the failure occurs. The database returns the consistent status Action 13.2 storage structure and data access

This section assumes that the storage structure and data access model for recovery are discussed.

Split the storageEasy to lose memory(Primary storage, cache, etc.) andNon-Easy memory loss(Disk tape, flash memory, non-loss RAM, etc.), then we assume an idealStable Storage(Stable storage), will not affect the storage data content in the event of any failure

DefinitionPhysical BlockFor disks stored on non-easy-to-lose disks,Buffer BlockIs to store the block in the easy-to-lose primary storage, andPrivate SpaceIt refers to the virtual storage area allocated for each transaction T independent of other transactions. You can name four operations:

Input (A): load the physical block from the disk to the primary storage output (A): Write the buffer block in the primary storage back to the disk read (X ): read the buffer block from the primary storage to the private space write (X): write the local copy in the private space back to the primary storage

Assume that in a transaction, the DBMS calls a read operation to load the block X to the private buffer when it first accesses block X, and writes write (X) back to the primary memory when the transaction is executed, during the operations in the transaction, only the local copy is modified.

Note that the DBMS does not need to call output every time it writes, depending on the OS write-back policy.

13.3 log-based recovery

LogsIs a set of records in the idealStable StorageDatabase storage records on, conventions:

When the transaction Ti starts, the log records <Ti, start> when the transaction Ti performs the write operation, the log records <Ti, X, old_value, new_value> when the transaction Ti ends, the log records <Ti, commit> at most one transaction is active at any time

Log-based recoveryThere are two policies,Postpone database ModificationAndModify database now

(1) postpone database Modification

In the deferred database modification mode, the database modification operations are only recorded in the Log, but the write operations are not implemented until the partial committed operation is performed.

Define the redo and undo operations when a failure occurs:

Redo: write the new value new_valueundo again according to <Ti, X, old_value, new_value> in the Log: unwrite the new value according to <Ti, X, old_value, new_value> in the Log, write old_value

Defined by the delayed database modification mode, transactions that have not been recorded <Ti, commit> do not perform any recovery operations, but have been recorded <Ti, commit> transactions perform redo operations sequentially (In this mode, old_value does not need to be recorded)

(2) modify the database immediately

The current database modification mode is opposite to the deferred database modification mode. Before a transaction is committed, it is allowed to modify the database. write-ahead logging rule (WAL rule) specifies that the log record must be completed before the database is written.

When the database is modified immediately, transactions that do not record <Ti, commit> must execute the undo operation in reverse order to return the database to a consistent state, but only records <Ti, the commit> transaction executes the redo operation sequentially.

(3) Check Points

Each redo and undo operation traverses the entire Log and completes the redo and undo operations of all transactions. The overhead is huge, and there is no significance for the redo logs written to the disk by output after the commit operation, therefore, the <checkpoint> statement is introduced in Log.

DBMS periodically performsCheckWork, write all commit transactions (written into the primary storage) back to the disk from the primary storage, and record a <checkpoint> in the log; note that during the check, a transaction may not be commit

When a database with a checkpoint is restored, you only need to restore the most recent transaction for each error:

Repeat the log in the reverse direction until the first <checkpoint> is found to continue the reverse traversal and locate the starting point of the last uncommitted transaction <Ti, start> from this sentence to execute the response redo and undo operations.

In the following sequence diagram, when a failure occurs (change the database mode immediately ):

T1 is ignored redo T2 and T3undo T413.4 shadow Database

In addition to log-based recovery, the Shadow Database has the following settings:

Assume that only one active transaction db_pointer pointer always points to the current consistent copy of the database. All updates are completed on the shadow copy of the database, the copy in the shadow copy is written to the disk only after the transaction partial committed, and the update db_pointer transaction fails to switch to the consistent database pointed to by db_pointer. The current shadow database is deleted directly. If the disk does not fail

The replication policy of the Shadow database is very inefficient in large databases.

13.5 recovery of concurrent transactions

The Log-based recovery described in 13.3 is for a single active transaction. More assumptions are completed below.Recovery of concurrent transactions:

All transactions share one storage buffer and one log record. One buffer block can contain multiple transactions. The modified data concurrency control strictly follows the Two-Phase Lock (detailed description in the next chapter ), ensure that the logs of concurrent transactions are invisible between transactions without commit. When a checkpoint occurs, multiple transactions may be active, recording <checkpoint, L>, L indicates the transaction list that is active when the checkpoint occurs. If the transaction list fails, execute the following action: Initialize the undo_list and redo_list empty tables, and find the first <checkpoint, L> in reverse order, add undo_list to the update of each transaction in L in reverse order of Log records, and add redo_list to the forward order to execute operations in undo_list and redo_list 13.6 Cache Management (1) Log record Cache

If the Log is cached in the primary storageThe cache is full.OrLog forceDuring operations, Log records (all) are written to the disk (multiple log records can be output at a time to reduce I/O overhead). In addition, the Log record cache must comply with the following conventions:

Log records must be output in sequence into disk transactions. Ti. Only when <Ti, commit> is written to the disk can log into the Committed State. log records must be written to the disk before the modified data is written to the disk (2) database cache

Database cacheUnlike the Log record cache, the cache is divided into blocks. When the cache is full, the cache block is replaced by a new block (if modified, it needs to be written back to the disk) instead of the entire cache

13.7 non-Loss memory failure

The above discussion on recovery only contains the part of the memory with high loss. The recovery of non-memory with high loss also utilizes a similar hierarchical memory idea: adding a dump operation, which is ideal for the next level.Stable Storage(It can be imagined as a storage medium with a lower level such as tape)