Berkeley DB Reference Guide: Transaction Protected Applications

Performing Checkpoints

The second component of the infrastructure, performing
checkpoints, is necessary for two reasons. First, you can only remove
the Berkeley DB log files from your system after a checkpoint. Second, the
frequency of your checkpoints is inversely proportional to the amount of
time it takes to run database recovery when the system or application
fails.

As transactions commit, records are written into the log files, but
the actual changes to the database are not written into the filesystem.
When a checkpoint is performed, all changes to the database which are
part of committed transactions are written into the filesystem.

Once the database pages are written, log files can be archived and removed
from the system because they will never be needed for anything other than
catastrophic failure. In addition, recovery after system or application
failure only has to redo or undo changes since the last checkpoint, since
it is known that changes before the checkpoint have all been flushed to
the filesystem.

Berkeley DB provides a separate UNIX-style utility, named db_checkpoint,
which can be used to perform checkpoints.
Alternatively, applications can write their own checkpoint utility using
the underlying txn_checkpoint function.

As checkpoints can be quite expensive, choosing how often to perform a
checkpoint is a common issue needing consideration when tuning Berkeley DB
applications.