Database recovery strategy

Recovery of transaction failure

Transaction failure ： Transaction terminated before running to normal termination

Recovery method

The recovery subsystem uses log files to undo （UNDO） Changes made to the database by this transaction
The recovery of transaction failure is automatically completed by the system , Transparent to users , No user intervention is required

Recovery steps for transaction failure

（1） Reverse scan file log （ That is, scan log files from the last forward ）, Find the update operation of the transaction .
（2） Reverse the update operation of the transaction . Is about to log “ Value before update ” Write to database .
The insert , “ Value before update ” It's empty , It is equivalent to deleting
Delete operation ,“ Updated value ” It's empty , It's equivalent to inserting
If it's a modification , It is equivalent to replacing the modified value with the pre modified value
（3） Continue reverse scanning log files , Find other update operations for this transaction , And do the same thing .
（4） Deal with it like this , Until you read the start tag of this transaction , Transaction recovery is complete .

Recovery of system failure

The reason of database inconsistency caused by system failure

The update to the database by the unfinished transaction may have been written to the database
The database update by committed transaction may be left in the buffer before it can be written to the database

Recovery method

1.Undo Unfinished transactions at the time of failure
2. Redo Completed transactions
The recovery of system failure is automatically completed when the system is restarted , No user intervention is required

Recovery steps for system failure

（1） Forward scanning log files （ Scan log files from scratch ）
redo (REDO) queue : Transactions committed before the failure
These things already have BEGIN TRANSACTION Record , Also have COMMIT Record
revoke (UNDO) queue : Unfinished business at the time of failure
These things are just BEGIN TRANSACTION Record , There is no corresponding COMMIT Record
（2） To revoke (UNDO) Queue transactions to undo (UNDO) Handle
Reverse scan log files , Reverse the update operation of each undo transaction
Is about to log “ Value before update ” Write to database
（3） To redo (REDO) Queue transactions redo (REDO) Handle
Forward scanning log files , Re perform the registration operation for each redo transaction
Is about to log “ Updated value ” Write to database

Recovery of media failure

Recovery steps

（1） Mount the latest backup database copy ( The most recent crash of the replica occurred at the time of the dump ) , Restore the database to the consistency state of the last dump .
For a database copy of a static dump , The database is in a consistent state after loading
For a database copy of a dynamic dump , You must also load a copy of the log file at the time of the dump , Use the method of recovering system failure （ namely REDO+UNDO）, To restore the database to a consistent state .
（2） Load a copy of the log file in question ( Copy of the log file at the end of the dump ) , Redo what has been done .
First scan the log file , Find out the ID of the transaction that was committed when the failure occurred , Put it in the redo queue .
Then forward scan the log file , Redo all transactions in the redo queue . Is about to log “ Updated value ” Write to database .

The recovery of media failure requires the intervention of database administrator

The work of Database Administrator
Reinstall the database copy of the latest dump and the copies of the related log files
Execute the recovery command provided by the system
The specific recovery operation is still completed by the database management system
Welcome to join me for wechat exchange and discussion （ Please note csdn Add ）