table of Contents
I. Overview of database recovery
1.2 The basic idea of recovery
Second, log-based recovery technology
2.1.2 Principles of registered log
2.2.1 update delayed recovery technology-based transaction failure
2.2.2 update delayed recovery technology based on system failure
2.3 real-time update technology
2.3.1-based instant update technology transaction failure recovery
2.3.2-based instant update technology System Recovery
Third, based on the checkpoint recovery technology
3.2 based system failure checkpoint recovery
Fourth, the media Recovery Technology
4.1.1 Static and dynamic dump dump
4.1.2 Mass Storage and incremental storage
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 mortality
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 running transactions are terminated in an irregular manner
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
cause
- 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 durability
Database system mainly through the registration log and data dump establishing redundant data
Data redundancy for fault 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
Logging must strictly follow the chronological order of execution of concurrent transactions registered
You must diary, written after the database
2.1.3 redo sum undo
the redo (Ti) according to the log record, the new value in the order of registration log, update the transaction data object each time Ti is rewritten with the database write operation (not re-executing the transaction Ti)
Use the undo old value (Ti) according to the log record, the log in reverse order of registration, each updated Ti transaction data object written to the database with write operations
undo and redo 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
Follow the rules
- Each transaction can not update the database before it reaches the point of submission
- 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 commit point, and therefore Ti update operations are registered in the log, not output to the database
When the transaction Ti fails, simply clear the log Ti transaction logging, database itself without the need 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 log records having <of Ti , transaction Ti commit>; the other is uncommitted transaction list that contains log records having <Tj , Start> but without logging <Tj , the 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 to the , Xj = V2 will be written to the database
2.3 real-time update technology
Real-time update technology allows the transaction will be updated into the database output in the active state
The transaction is active directly on the implementation of the database update called non-submission updates
Follow the rules
- Before logging <Ti, Xj, V1, V2> secure a stable output to the memory transaction Ti Xi = V2 can not update the database
- 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
When transaction Ti fails, it may have been some updates to the database output, so you must execute undo (Ti)
Until it encounters a reverse scan log file <of 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 log records having <of Ti , transaction Ti commit>; the other is uncommitted transaction list that contains log records having <Tj , Start> but without logging <Tj , the commit> of transaction Tj
2, performing undo (Ti) of each uncommitted transaction listing transaction 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
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 to the , 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.
- T1: submitted before the checkpoint
- T2: start executing before the checkpoint, submitted before the point of failure after the checkpoint
- T3: begin before a checkpoint, when the fault point has not been completed
- T4: started after the checkpoint, submitted before the point of failure
- 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
- Obtain a last checkpoint record: find last checkpoint address recorded in the log file, remove the last checkpoint record <the checkpoint , L>
- 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
- 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 , the commit> put the Ti moved from UNDO-LIST REDO-LIST
- 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
- 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
Offline backup copies can be saved, used for media failure recovery
4.1.1 Static and dynamic dump dump
When the dump from the perspective of whether to allow the transaction to run
Static dump is a dump taken when the system is running without a transaction; surely get a consistent copy , but reduces concurrency database
Dynamic dump dump operation and allows concurrent execution of a user transaction, the transaction during a dump allows access and update the database; not guarantee a consistent copy of the data
4.1.2 Mass Storage and incremental storage
It is to dump the entire database or part database dump from the point of view
Massive dump complete copy of the database
Incremental dump copying only updated after the dump this data, the increment copy of the database is formed, can not be used alone incremental copies
When 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
- Load the latest backup copy of the database, the database will be restored to the state when the last dump
- After logging into the dump, redo completed transactions