Database Review 7--Recovery

Database Review CH14 Recovery 13.1 Concept

recovery In a database system is the behavior of having the database revert to a normal, consistent state from the inconsistent state that occurred after some "failure", the basis of which is redundancy (physically redundant, non-logical)

These failures include the following:

• Transaction failure: Includes logic error (transaction does not meet certain conditions cannot be performed) and system error (DBMS forces termination of transaction, such as transaction deadlock)
• System crashes: Power outages, physical hardware corruption, software systems (such as OS) crashes, this chapter assumes that a system crash does not change non-volatile memory
• Disk failure: Disk storage error, this chapter assumes the use of inspection and monitoring disk failure

Basically, the recovery strategy is divided into two steps:

• When normal transactions are processed, sufficient additional information is logged for the recovery to fail
• After a failure occurs, the action that the database returns a consistent state

13.2 storage structure and data access

This section assumes the storage structure and the data access model when discussing recovery issues

If the system crashes, it affects the data storage, divides the memory into volatile memory (main memory, cache, etc.) and nonvolatile memory (disk tape, flash memory, nonvolatile RAM, etc.), then we assume an ideal stable memory (Stable storage), which does not affect the storage of data content when any failure occurs

Define a block that is stored on a non-volatile disk, where the buffer block is a block stored in the volatile main memory, and the private space refers to a virtual storage area that is separate from other transactions for each transaction T, then you can name 4 operations:

• Input (A): Loading physical blocks from disk to main memory
• Output (A): Write buffer block back to disk in main memory
• Read (X): reads buffer blocks from main memory to private space
• Write (X): Writes a local copy of the private space back to main memory

Suppose that in a transaction, the DBMS invokes a read operation to the private buffer at the first access to the Block X, and write (X) writes back to main memory when the transaction completes, while the operation in the middle of the transaction simply modifies its local copy

Note that it is not necessary for the DBMS to invoke output on each write, depending on the writeback policy of the OS

13.3 Log-based recovery

A log is a set of database storage records that are recorded on an ideal stable storage , with the following conventions:

• When the transaction TI starts, the log record<Ti, start>
• When transaction TI performs a write operation, logging<Ti, X, old_value, new_value>
• When the transaction ti ends, the log records<Ti, commit>
• At most only one transaction is active at any time

Log-based recovery has two strategies for delaying database modification and immediate database modification

(1) Postpone database modification

Deferred database modification mode, the database modification operation is logged only in log and does not actually implement the write operation until the partial committed is not write

Define the redo and undo actions when a failure occurs:

• Redo: <Ti, X, old_value, new_value> writes the new value again according to log New_value
• Undo: Writes <Ti, X, old_value, new_value> Old_value to the undo new value in log

By delaying the definition of the database modification mode, the non-logged <Ti, commit> transaction does not perform any recovery operations, and <Ti, commit> the logged transactions perform the redo operation sequentially (in fact, Old_value is not required to record in this mode)

(2) Immediate database modification

Immediate database modification mode and deferred database modification mode instead, the database is allowed to be modified before the transaction commits, write-ahead logging rule (Wal rules) stipulates that log records must be completed before the database is written

Immediately under database modification, an unregistered <Ti, commit> transaction must perform an undo operation in order to return the database to a consistent state, and <Ti, commit> the logged transaction executes the redo operation sequentially

(3) Checkpoint

Each time redo and undo traverse the entire log and complete the redo and undo of all transactions, the overhead is enormous and there is no sense in redo that the output is written to the disk after the commit, so the log introduces the <checkpoint> statement

The DBMS periodically checks that all commit transactions (write master) are written back to disk from main memory, and a record is recorded in the log <checkpoint> ; note that when checking, a transaction may not have been commit

With a checkpoint database recovery, you only need to recover the most recent transaction per error:

1. The log is traversed backwards until the first one is found<checkpoint>
2. Continue the reverse traversal to find the last non-commit transaction starting point<Ti, start>
3. Redo and undo actions to start the response from this sentence

Then for the following sequence diagram, there is a failure (immediate database modification mode):

• T1 is ignored
• Redo T2 and T3
• Undo T4

13.4 Shadow Database

In addition to log-based recovery, there is another recovery strategy-the Shadow Database (Shadow), which has the following settings

• Assuming 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 done on a shadow copy of the database (shadow copy), and the copy in shadow copy is written to disk only after the transaction partial committed, and the update db_pointer
• When a transaction fails, it turns to a consistent database that db_pointer points to, and the current shadow database is deleted directly
• Assuming the disk does not fail

Copy policy of shadow database is inefficient in large database

13.5 Recovery of concurrent transactions

The log-based recovery described in 13.3 is for single-active transactions, and there are more assumptions that the recovery of concurrent transactions has completed:

• All transactions share a single copy of the storage buffer and one log record
• A buffer block can have more than one transaction modified data
• Concurrency control strictly follows a two-phase lock (detailed in the next chapter) to ensure that non-committed transactions are not visible between
• Log of concurrent transactions can be intertwined
• When a checkpoint occurs, multiple transactions may be active, logged <checkpoint, L> , and L is the list of transactions that are active when the checkpoint occurs
• Perform an action when a failure occurs: Initialize undo_list and redo_list empty table, find first in reverse order <checkpoint, L> , and update for each transaction in L by log record undo_list , join in sequenceredo_list
• Perform undo_list and redo_list actions in

13.6 Cache Management (1) log record cache

If log is cached in main memory, log records (all) are written to disk (so that multiple log records can be output at once, reducing I/O overhead) When the cache is full or log force is operational. In addition, the log record cache must comply with the following conventions:

• Log records must be sequentially output into disk
• Transaction TI <Ti, commit> can enter committed state only after writing to disk
• Log records must be written to disk before the corresponding modified data

(2) Database Cache

The Database cache and log record cache are not the same, it is partitioned cache, when the cache is full when the selection cache block is replaced by the new block (if the modification needs to write back to the disk), and not the entire cache writeback

13.7 Failure of nonvolatile memory

The above discussion of recovery contains only the parts of volatile memory, and the recovery of nonvolatile memory also utilizes similar layered memory ideas: Adding an dump operation that is the ideal stable memory (which can be assumed to be a lower level of storage media such as tape)

Database Review 7--Recovery