- Berkeley DB Reference Guide:
- Transaction Protected Applications
|
|
The second component of the infrastructure is performing checkpoints of the log files. As transactions commit, records are written into the log files, but the actual changes to the database may not be written to disk. When a checkpoint is performed, the changes to the database which are part of committed transactions are written into the database.
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 after a system or application failure.
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 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 tuning parameter for Berkeley DB applications.
|
|