When a DBMS restarts after a crash, log‑based recovery scans the entire transaction log (or a large part of it) to decide which transactions to redo and which to undo. For a busy system with a very long log, this can be very slow.

Checkpointing is a technique that periodically “saves the current state” of the database so that, during recovery, the DBMS can ignore the older part of the log and start from the last checkpoint instead. This speeds up recovery significantly.

What Is a Checkpoint?

A checkpoint is a special marker written into the log that says:

“At this moment, all transactions that committed before the checkpoint have had their changes fully written to the database, and no recovery is needed for them.”

In simple terms, a checkpoint is a saved snapshot of consistency in the system.

During a checkpoint, the DBMS usually does several things:

  • Write all modified pages from memory (buffer pool) to disk.

  • Record in the log the list of active transactions at that moment.

  • Write a checkpoint record into the log (for example, START CKPT(T1, T2); END CKPT).

This checkpoint record becomes the starting point for the next recovery.

How Checkpointing Reduces Recovery Time

Without checkpointing, after a crash the DBMS must:

  • Scan the entire log from the beginning,

  • Decide which transactions were committed and which were not,

  • Perform redo and undo accordingly.

With checkpointing:

  • The DBMS jumps directly to the last checkpoint record in the log.

  • It only needs to:

    • Redo changes of transactions that committed after the checkpoint.

    • Undo changes of transactions that started before the checkpoint but did not commit by the time of the crash.

This typically means scanning much less of the log, which makes recovery faster and more predictable.

When Are Checkpoints Written?

Checkpoints can be created in different ways:

  • Periodic checkpoints:

    • Written every fixed time interval (for example, every 10 or 30 minutes).

  • Event‑driven checkpoints:

    • Written after a certain amount of log has been written, or after a large number of transactions.

  • Forced checkpoints:

    • Taken when the DBA explicitly forces one (for example, before a maintenance window).

The choice of frequency is a trade‑off:

  • More frequent checkpoints → faster recovery but more overhead (more disk writes and log entries).

  • Less frequent checkpoints → slower recovery but less overhead.

Why Checkpointing Matters for Beginners

  • It shows how recovery is optimized, not just “correct”.

  • It connects log‑based recovery with real‑world performance: checkpoints help a large database come back quickly after a crash.

  • It is the reason why modern DBMS can handle huge amounts of data and still recover in reasonable time.

Summary

Checkpointing in DBMS is a recovery optimization technique that periodically writes a checkpoint record into the transaction log, indicating that all prior committed transactions are safely on disk. During recovery, the DBMS starts from the last checkpoint instead of the beginning of the log, so it only needs to scan a smaller part of the log. This dramatically reduces recovery time, making checkpointing essential for the performance and reliability of log‑based recovery in large databases.