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.
