Recovery technology with checkpoints

Problem presentation

Two questions

Searching the entire log will take a lot of time
Redo processing ： Re execution , Wasted a lot of time

Solution

With checkpoints （checkpoint） Recovery technology
Add checkpoint records to the log file （checkpoint）
Add restart file
The recovery subsystem dynamically maintains the log during log file login

Checkpoint Technology

What the checkpoint records

Create a list of all transactions that are executing at checkpoint time
The last logged address of these transactions

Restart the contents of the document

Record the address of each checkpoint recorded in the log file

How to maintain log files dynamically

Periodically do the following ： Set up checkpoints , Save database state .
The specific steps are ：
（1） Write all the log records in the current log buffer to the log file on disk
（2） Write a checkpoint record in the log file
（3） Write all data records of the current data buffer to the database of the disk
（4） Write the address of the checkpoint recorded in the log file to a restart file

Set up checkpoints

The recovery subsystem can establish checkpoints periodically or irregularly , Save database state
regular
At a predetermined time interval , For example, set up a checkpoint every hour
Irregular
According to some rules , If the log file is half full, create a checkpoint

Recovery strategy utilizing checkpoints

Using checkpoint methods can improve recovery efficiency

When a transaction T Submit... Before a checkpoint ,T Changes made to the database have been written to the database
The write time is before or when the checkpoint is established
In recovery processing , There is no need to T Perform redo operation
When the system fails , The recovery subsystem will adopt different recovery strategies according to different transaction states

T1： Submit... Before checkpoint
T2： Start execution before checkpoint , Submit after checkpoint and before fault point
T3： Start execution before checkpoint , Not completed at the point of failure
T4： Start execution after checkpoint , Submit... Before the point of failure
T5： Start execution after checkpoint , Not completed at the point of failure

Recovery strategy

T3 and T5 Not completed at the time of failure , So it was revoked
T2 and T4 Submit after checkpoint , The changes they make to the database may still be in the buffer at the time of the failure , Not yet written to the database , So do it again
T1 Submitted before checkpoint , So you don't have to redo

Recovery steps using checkpoints

（1） Find the address of the last checkpoint recorded in the log file... From the restart file , This address finds the last checkpoint record in the log file
（2） The checkpoint records the list of all transactions being executed at the checkpoint establishment time ACTIVE-LIST
Create two transaction queues
UNDO-LIST
REDO-LIST
hold ACTIVE-LIST Put in for a while UNDO-LIST queue ,REDO The queue is temporarily empty .
（3） Scan log files forward from checkpoint , Until the end of the log file
If there is a new beginning Ti, hold Ti Put in for a while UNDO-LIST queue
If there are committed transactions Tj, hold Tj from UNDO-LIST The queue moves to REDO-LIST queue ; Until the end of the log file
（4） Yes UNDO-LIST Each transaction in performs UNDO operation
Yes REDO-LIST Each transaction in performs REDO operation
Welcome to join me for wechat exchange and discussion （ Please note csdn Add ）