Open In App

Checkpoints in DBMS

Last Updated : 22 May, 2025
Comments
Improve
Suggest changes
Like Article
Like
Report

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.

Checkpoints in Real Time

In a real-time environment, transaction logs are continuously created, which can consume a significant amount of storage space. Tracking and maintaining every update may also increase the physical storage requirements of the system. Over time, the transaction log file can grow so large that it becomes difficult to manage effectively. This issue is addressed through the use of checkpoints.

A checkpoint is a process that removes all previous transaction logs from active storage and saves the necessary information to permanent storage. This helps control the size of the transaction log and improves system efficiency.

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:

Checkpoints in multiple Transactions
Understanding Checkpoints in multiple Transactions

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

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.

Advantages of Checkpoints in DBMS

  • Facilitates Transaction Recovery : Checkpoints help recover the database in case of a sudden or unexpected shutdown by marking a point from which recovery can resume efficiently.
  • Enhances Database Consistency : They ensure consistency even when multiple transactions are executing simultaneously by writing modified data to disk at regular intervals.
  • Speeds Up Data Recovery : By reducing the number of log records that need to be processed during recovery, checkpoints significantly speed up the recovery process.
  • Acts as a Synchronization Point : Checkpoints serve as a synchronization point between the transaction log and the database, ensuring that all committed changes are written to disk.
  • Reduces Redo Operations : Checkpoint records in the log file help avoid unnecessary redo operations, making recovery more efficient.
  • Low Overhead : Since dirty pages are flushed to disk continuously in the background, checkpoints introduce minimal overhead and can be performed frequently.
  • Provides Baseline for Recovery : They provide the baseline information necessary for restoring the lost state of the database after a system crash.
  • Supports Incremental Backups : By tracking change information, database checkpoints enable incremental backups, saving storage and time.
  • Mountable Checkpoints for File Operations : Database storage checkpoints can be mounted, allowing regular file system operations such as browsing or copying.
  • Useful for Backup and Recovery Solutions : Checkpoints are integral to application-level solutions for backup, recovery, and database modifications.

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).

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.

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.

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.

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.

For more information you can refer to Transaction Management article.


Next Article
Article Tags :

Similar Reads