Steps to Use Checkpoints in the Database
- Write the begin_checkpoint record into a log.
- Collect checkpoint data in stable storage.
- Write the end_checkpoint record into a log.
The behavior when the system crashes and recovers when concurrent transactions are executed is shown below:
Transactions and operations of the above diagram:
Transaction 1 (T1) | Transaction 2 (T2) | Transaction 3 (T3) | Transaction 4 (T4) |
---|---|---|---|
START | |||
START | |||
COMMIT | |||
START | |||
COMMIT | |||
START | |||
FAILURE |
- The recovery system reads the logs backward from the end to the last checkpoint i.e. from T4 to T1.
- It will keep track of two lists – Undo and Redo.
- Whenever there is a log with instructions <Tn, start>and <Tn, commit> or only <Tn, commit> then it will put that transaction in Redo List. T2 and T3 contain <Tn, Start> and <Tn, Commit> whereas T1 will have only <Tn, Commit>. Here, T1, T2, and T3 are in the redo list.
- Whenever a log record with no instruction of commit or abort is found, that transaction is put to Undo List <Here, T4 has <Tn, Start> but no <Tn, commit> as it is an ongoing transaction. T4 will be put on the undo list.
All the transactions in the redo list are deleted with their previous logs and then redone before saving their logs. All the transactions in the undo list are undone and their logs are deleted.
Checkpoints in DBMS
Pre-Requisite: Transaction Management
The Checkpoint is used to declare a point before which the DBMS was in a consistent state, and all transactions were committed. During transaction execution, such checkpoints are traced. After execution, transaction log files will be created. Upon reaching the savepoint/checkpoint, the log file is destroyed by saving its update to the database. Then a new log is created with upcoming execution operations of the transaction and it will be updated until the next checkpoint and the process continues.