Database review 7 -- recovery, database review 7

Database review 7 -- recovery, database review 7
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 will not change non-Easy memory loss.
• Disk failure: disk storage error. This chapter assumes that disk inspection and monitoring can fail.

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

• During normal transaction processing, sufficient additional information is recorded for recovery upon failure.
• When a failure occurs, the database returns a consistent state.

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 A 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 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:

• Log records when transaction Ti starts<Ti, start>
• When transaction Ti executes the write operation, the log records<Ti, X, old_value, new_value>
• Log records when transaction Ti ends<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:<Ti, X, old_value, new_value>Write the new value new_value again.
• Undo: according to<Ti, X, old_value, new_value>Unwrite New Value write, that is, write old_value

Definition of delayed database modification mode, not recorded<Ti, commit>The transaction does not perform any recovery operations, which have been recorded<Ti, commit>In this mode, there is no need to record old_value)

(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.

Modify database now, not recorded<Ti, commit>The transaction must execute the undo operation in reverse order to make the database return to the consistent state, only records<Ti, commit>To execute redo operations in sequence.

(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<checkpoint>Statement

DBMS periodically performsCheckWork, write all commit transactions (written into the primary storage) back to the disk from the primary storage, and record<checkpoint>; Note: 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:

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

• T1 ignored
• Redo T2 and T3
• Undo T4

13.4 shadow Database

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

• Assume that only one transaction is active at any time.
• The db_pointer pointer always points to the current consistent copy of the database.
• All updates are completed on the shadow copy of the database. Only after the transaction partial committed writes the copies in the shadow copy to the disk and updates db_pointer.
• When a transaction fails, the database directed to db_pointer is switched to a consistent database. 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.
• A buffer block can contain data modified by multiple transactions.
• Concurrency control strictly follows the Two-Phase Lock (detailed description in the next chapter) to ensure that transactions that are not committed are invisible.
• The logs of concurrent transactions can be intertwined.
• When a checkpoint occurs, multiple transactions may be active and recorded.<checkpoint, L>, L is the list of active transactions at the checkpoint
• Execute the following action when a failure occurs: initializationundo_listAndredo_listEmpty table. Find the first table in reverse order.<checkpoint, L>For the update of each transaction in L, it is added in the reverse order of Log recordsundo_listAdding in positive orderredo_list
• Runundo_listAndredo_listActions in

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 to the disk sequentially.
• Transaction Ti only works when<Ti, commit>Write to disk before entering the Committed status
• Log records must be written to the disk before the modified data is written.

(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: AdddumpOperation. The next level is ideal.Stable Storage(It can be imagined as a storage medium with a lower level such as tape)