1INBerkeley DB Reference Guide: Transaction Protected Applications[PH

Berkeley DB Reference Guide: Transaction Protected Applications



,

Performing Checkpoints



9The second component of the infrastructure, performingJcheckpoints, is necessary for two reasons. First, you can only removeKthe Berkeley DB log files from your system after a checkpoint. Second, theHfrequency of your checkpoints is inversely proportional to the amount ofEtime it takes to run database recovery when the system or applicationfails.

CAs transactions commit, records are written into the log files, butGthe actual changes to the database are not written into the filesystem.EWhen a checkpoint is performed, all changes to the database which are?part of committed transactions are written into the filesystem.

JOnce the database pages are written, log files can be archived and removedIfrom the system because they will never be needed for anything other thanHcatastrophic failure. In addition, recovery after system or applicationIfailure only has to redo or undo changes since the last checkpoint, sinceGit is known that changes before the checkpoint have all been flushed tothe filesystem.

wBerkeley DB provides a separate UNIX-style utility, named db_checkpoint,)which can be used to perform checkpoints.HAlternatively, applications can write their own checkpoint utility usingZthe underlying txn_checkpoint function.

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

PAPÿÿ