Checkpoints in DBMS

A checkpoint marks a point in time where the DBMS ensures that the database is in a consistent state and all prior transactions have been committed. During transaction execution, these checkpoints are recorded periodically.

After a checkpoint is reached:

• The transaction log up to that point can be safely discarded, as all corresponding updates have already been written to the database.
• A new log file is then created to record changes from subsequent transactions.
• This process continues, allowing the system to limit the amount of log data and improve recovery efficiency by avoiding scanning the entire log history.

In a real-time system, transaction logs keep growing as updates happen, which can take up a lot of storage. This makes them hard to manage over time.

Checkpoints help solve this by saving the current state of the database to permanent storage and clearing old logs. This keeps the log size small and improves system performance.

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:

Recovery Rule Summary

• Redo List: Transactions that have a COMMIT log (whether or not a START is shown).
• Undo List: Transactions that have a START but no COMMIT or ABORT i.e., incomplete transactions at the time of failure.

Transaction Analysis

T1:

• Has <START> but no COMMIT.
• Goes to Undo List.

T2:

• Has <START> and <COMMIT>.
• Goes to Redo List.

T3:

• Has <START> and <COMMIT>.
• Goes to Redo List.

T4:

• Has <START> but no COMMIT.
• System failed while T4 was running.
• Goes to Undo List.

Final undo and redo list :

• Redo List: T2, T3
• Undo List: T1, T4

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. 

Types of Checkpoints

There are basically two main types of Checkpoints:

Automatic Checkpoint

• These checkpoints occur at regular intervals, such as every hour or every day.
• The frequency is configured by the database administrator (DBA).
• They are commonly used in large or heavily used databases where frequent updates occur.
• Automatic checkpoints help ensure that data can be recovered quickly and efficiently in case of a system failure.

Manual Checkpoint

• These checkpoints are explicitly triggered by the DBA, rather than occurring on a set schedule.
• They are typically used in smaller or less active databases.
• Manual checkpoints are created infrequently, only when the DBA decides it is necessary (e.g., before maintenance or system upgrades).

Relevance of Checkpoints

A checkpoint is a crucial feature that contributes to the Consistency (C) in the ACID properties of a relational database management system (RDBMS). It plays a vital role in database recovery, especially in the event of an unexpected shutdown or crash.

Checkpoints occur at regular intervals and perform the following actions:

• They write all dirty pages (i.e., modified pages that reside in memory) from the buffer cache to the physical disk.
• This process is often referred to as the hardening of dirty pages.
• The checkpoint acts as a synchronization point between the transaction log and the database files, ensuring that committed changes are safely stored on disk.

In systems like SQL Server, checkpoints run automatically at defined intervals and are managed as a dedicated background process.

Real-Time Applications of Checkpoints

Checkpoints play a vital role in database systems and offer several real-time applications, especially in the areas of backup and recovery, performance optimization, and auditing.

1. Checkpoint and Recovery: In the event of a system failure, the DBMS refers to the last checkpoint to recover the database to its last known consistent state.

• The recovery speed depends on how frequently checkpoints are created.
• Shorter intervals between checkpoints allow for faster recovery, as less log data needs to be processed.
• However, frequent checkpointing may impact performance due to the overhead of writing to disk more often.

2. Importance of Checkpoints in Performance Optimization: They reduce the amount of recovery work required by discarding unnecessary or already committed transaction data.

• This keeps the database clean and optimized.
• By minimizing the data that needs to be read from disk during recovery, checkpoints enhance overall system performance and reduce downtime.

3. Checkpoints and Auditing

• They provide a historical reference that allows administrators to track changes or issues in the database.
• In case of a failure, checkpoints help determine the exact time and scope of data affected.
• This enables better investigation, accountability, and troubleshooting during audits or forensic analysis.

Advantages of Checkpoints

• Enable Faster Recovery: Checkpoints mark a safe state to resume recovery after a crash, reducing the number of log records to process.
• Ensure Consistency: They write modified data to disk regularly, maintaining consistency during multiple transactions.
• Sync Log and Database: Act as a sync point, making sure all committed changes are saved to disk.
• Reduce Redo Operations: Help avoid redoing unnecessary changes during recovery.
• Low Performance Overhead: Checkpoints run in the background with minimal impact on system performance.
• Support Backups: They allow incremental backups and aid in reliable backup and restore operations.

Disadvantages of Checkpoints

• Recovery from Logical Errors : Database storage checkpoints can be used to restore the database to a previous consistent state in the event of logical errors, such as accidental data deletion or incorrect updates caused by human error.
• Limitation in Media Failure : Since all data blocks reside on the same physical storage device, database storage checkpoints cannot be used to recover data in the event of a media failure (e.g., disk crash or hardware corruption).

For more information you can refer to Transaction Management article.