Introduction to Database Systems - recovery techniques

I. Overview of database recovery

DBMS recovery sub-system must be able to restore a database to ensure a consistent state after a failure, some, to minimize losses, and the collapse time after the database can not be used minimized

1.1 Fault Classification

1.1.1 transaction failure

A transaction during operation due to various reasons, unable to run properly terminated and died
two errors led to execution failed transactions

• Program logic errors
• system error

1.1.2 System Fault

For some reason the normal operation of the whole system suddenly stopped, causing all transactions are running to abnormal termination of
the cause

• DBMS or operating system error codes
• Operator operational errors
• Specific types of hardware error (CPU fault)
• Sudden power failure, etc.

1.1.3 media failure

Store database storage device failure
causes

• Disk corruption
• Head crash
• The operating system some potential errors
• Instantaneous strong magnetic interference

1.2 The basic idea of ​​recovery

The establishment of redundant data in the system during normal operation, to ensure there is enough information available for recovery. After the failure to take measures to restore the contents of the database to a consistent state, to ensure atomicity and persistence
database systems, mainly through registration logs and data dumps establish redundant data
redundancy data recovery considerations

• The nature of memory
• When the transaction is written to the database update
• buffer

Second, log-based recovery technology

2.1 log

Log is a log sequence records all activity in the database update

2.1. 1 logger record format

An update log record a transaction once write operation of the database, including

• Transaction identifier
• Action Type
• Operation object
• The old value
• The new value

<Ti,start>     --事务Ti开始
<Ti,Xj,V1,V2>  --事务Ti对 Xj的一次更新，其中 V1是旧值，V2是新值。对于插入，V1为空；对于删除，V2为空
<Ti,commit>    --事务Ti正常提交
<Ti,abort>     --事务Ti异常终止

2.1.2 Principles of registered log

Time logging must strictly follow the order of simultaneous transactions executed registration
must diary, written after the database

2.1.3 redo sum undo

The new value of the redo (Ti) according to the log records, logs the order registration, update the transaction data object each time Ti with the write operation to re-written to the database (not re-execute the transaction Ti)
Use the undo (Ti) according to the log recording, press registration log in reverse order, the old value is updated each time a transaction Ti data objects written in write-back operation database
redo and undo are idempotent, perform multiple equivalent to the execution time

2.2 Delayed update technology

After the delay updates to the database update transaction postponed until the transaction commits
to follow the rules

1. Each transaction can not update the database before it reaches the point of submission
2. Before all the updates in a log record of the transaction is written to stable storage, the transaction does not reach a commit point

2.2.1 update delayed recovery technology-based transaction failure

When a transaction fails Ti, Ti does not reach the point of submission, so Ti update operations are registered in the log, not output to the database
when a transaction Ti fails, simply clear the log Ti transaction logging, without the database itself for further processing. If the fault is not in itself a transaction Ti logical errors, the transaction Ti can be restarted at a later time

2.2.2 update delayed recovery technology based on system failure

1. Forward scan log files, create two transactions list. Is a committed transaction list that contains transaction log records having Ti <Ti, commit>; the other is uncommitted transaction list that contains log records having <Tj, start> but without logging <Tj, commit> of transaction Tj
2. Ti perform the redo (Ti) for each transaction committed transaction list: forward scan log file, for each of the form <Ti, Xj, V1, V2> log records, the transaction list if Ti has been submitted, then Xj = V2 will be written to the database

2.3 real-time update technology

Real-time update technology allows a transaction in an active state will update the database to which the output
is active transactions implemented directly on the database update known as non-submitted updates
to follow the rules

1. Before logging <Ti, Xj, V1, V2> secure a stable output to the memory transaction Ti Xi = V2 can not update the database
2. Before all <Ti, Xj, V1, V2> Type securely logging output to stable storage, the transaction is not allowed to submit Ti

2.3.1-based instant update technology transaction failure recovery

Ti transaction fails, it may have some update the output to the database must perform Use the undo (Ti)
reverse scan log file until it encounters a <Ti, start>, for each of the form <Ti, Xj, V1, V2> log record written to the database to which Xj = V1

2.3.2-based instant update technology System Recovery

1. Forward scan log files, create two transactions list. Is a committed transaction list that contains transaction log records having Ti <Ti, commit>; the other is uncommitted transaction list that contains log records having <Tj, start> but without logging <Tj, commit> of transaction Tj
2. Uncommitted transactions for each transaction Ti list of execution undo (Ti): Reverse scan log file until it encounters the uncommitted list of transactions for each transaction of Tk <Tk, commit>, for each of the form <Ti, Xj, V1 , V2> logging, if Ti in uncommitted transactions list, it is written to the database Xj = V1
3. Ti perform the redo (Ti) for each transaction committed transaction list: forward scan log file, for each of the form <Ti, Xj, V1, V2> log records, the transaction list if Ti has been submitted, then Xj = V2 will be written to the database

Third, based on the checkpoint recovery technology

3.1 checkpoint

Methods to improve the efficiency of the recovery system is the use of checkpointing
assumes that the system set up time Tc the last checkpoint, at time Tf of the system failure, the transaction can be divided into five categories FIG.

1. T1: submitted before the checkpoint
2. T2: start executing before the checkpoint, submitted before the point of failure after the checkpoint
3. T3: begin before a checkpoint, when the fault point has not been completed
4. T4: started after the checkpoint, submitted before the point of failure
5. T5: started after the checkpoint has not been completed at the point of failure

3.2 based system failure checkpoint recovery

When a system failure occurs, you must first restart the system. After system restart, recovery subsystem automatically perform the following steps

1. Obtain a last checkpoint record: find last checkpoint address recorded in the log file, remove the last checkpoint record <checkpoint, L>
2. Two initialization list of transactions UNDO-LIST (set of transactions need to perform undo operations) and REDO-LIST (set of transactions need to perform redo operations): all transactions are placed in L UNDO-LIST, and REDO-LIST is empty
3. The establishment of two transactions list UNDO-LIST and REDO-LIST: starting from the most recent checkpoint, forward scan log files until the end of the encounter <Ti, start> put Ti added UNDO-LIST; encountered <Ti, commit> put the Ti moved from UNDO-LIST REDO-LIST
4. UNDO-LIST for each transaction performed Ti undo (Ti): log file until it encounters a reverse scan uncommitted transactions list of each transaction Tk <Tk, commit>, for each of the form <Ti, Xj, V1 , V2> logging, if Ti in uncommitted transactions list, it is written to the database Xj = V1
5. Ti perform the redo (Ti) REDO-LIST for each transaction: forward scan log file, for each of the form <Ti, Xj, V1, V2> log records, the transaction list if Ti has been submitted, then Xj = V2 will be written to the database

Fourth, the media Recovery Technology

4.1 dump

Copy the whole or part of a database to another disk or tape, produce back-up copy of the database
to use when backup copies can be saved offline, for media failure recovery

4.1.1 Static and dynamic dump dump

Dump angle from whether to allow the transaction to consider
static dump dump is no transaction is running on the system; must obtain a copy of the same, but reducing the database concurrency
dynamic dump allows a flush operation with user transactions concurrent execution, during a dump allows transactions to access the database and update; can not guarantee a consistent copy of the data

4.1.2 Mass Storage and incremental storage

Is to dump the entire database or a portion of the database from the viewpoint dump
massive dump produced a complete copy of the database
incremental dump copy only the dump this data after the update, the incremental copy of the database is formed, incremental copies can not alone the use of
recovery, you must use a full copy of the final and all incremental copies after the order to restore the database to a consistent state

4.2 Media Recovery

When the database is damaged, you need to restore a backup copy and log dumps, where only consider the massive dump

1. Load the latest backup copy of the database, the database will be restored to the state when the last dump
2. After logging into the dump, redo completed transactions