17. Backing Up and Restoring the Database : Backup by Checkpoints : Management of Checkpoint, Journal, and Dump Files
Share this page                  
Management of Checkpoint, Journal, and Dump Files
You must manage the files in the checkpoint, journal, and dump locations for each database.
Each time you take a checkpoint, a set of files in the ckp and dmp directories are created. In addition, between checkpoints, for each journaled database, more files are created in the jnl (journal) location. Each set of journal files is associated with the checkpoint at the start of the journal interval.
So, for backup and restore purposes, a checkpoint consists of checkpoint file(s) and associated journal and dump files.
References to the ckp and associated files are stored in the configuration file for the database. These references must be present to be used by backup and restore operations. To see this information, issue the following command at the operating system prompt:
infodb dbname
Most of the commands used to back up and restore data create or destroy the entire set of files and references associated with a checkpoint.
Checkpoint File Version Numbers
When you checkpoint a database, a checkpoint file is created for each location on which the database is stored. The names of the checkpoint files are in the format shown by the following example:
where v shows the version number of the checkpoint sequence and l shows the location number of the data directories. The most recent checkpoint file has the highest version number.
In the common case where the database has only one location, there will be one checkpoint file for each checkpoint called c000v001.ckp.
Vector can manage up to 99 checkpoints. If this limit is exceeded, the oldest checkpoint will be unusable because the database configuration file will contain no references to it. Before you reach this point, you may run out of disk space for either the checkpoints or journals. In most cases keeping 99 checkpoints on disk is not useful.
Keep N Checkpoints
The easiest way to manage checkpoints and their associated files is to decide how many checkpoints you want to be referenced in the database configuration file (so that you can restore the database directly from files on disk or from files restored from backup).
To keep n checkpoints
Add the following command after your routine checkpoint command:
alterdb dbname -keep=n
The specified number of latest valid checkpoints is preserved and all older checkpoints are deleted.
This command is sufficient for most purposes. Occasionally, however, you may need other commands, described next.
Maintaining Checkpoint Files Offline
If you do not have sufficient disk space for N sets of checkpoint and journal files, you must back up these files and manually delete them from disk.
In the context of a live database, the checkpoint, the associated files (with the same checkpoint number) in the dmp directory, and all subsequent journal files are required to be able to restore that database. So you should remove only the set of files associated with the oldest checkpoint each time.
In addition, if the live database configuration file is lost or broken, you will also need the aaaaaaaa.cnf file from the dmp directory. Because the files in the dmp directory are usually small, it is easiest to simply back up the entire dmp directory.
Delete Old Checkpoints Manually
If you do not have disk space for all the checkpoints referenced in the database configuration file, or if some of the files are not referenced (as indicated by infodb dbname), you must delete these files manually.
To delete old checkpoints manually
Use an operating system command, as follows:
Use the Linux rm command from the ii_checkpoint/ingres/ckp/dbname directory, where ii_checkpoint is the value of II_CHECKPOINT as displayed by the ingprenv command.
Additional Commands for Managing Checkpoints
Here are other commands for managing checkpoints and their associated files.
1. Delete the oldest checkpoint by using the alterdb ‑delete_oldest_ckp flag:
alterdb dbname -delete_oldest_ckp
The oldest checkpoint, including related journal and dump files, is deleted.
Warning: The –delete_oldest_ckp will delete the oldest checkpoint, even if you have only two. While you may think you have four, the number of entries in the configuration file is the determining factor. For this reason we recommend the ‑keep flag instead of -delete_oldest_ckp.
2. Delete invalid checkpoints by using the alterdb ‑delete_invalid_ckp flag. Use this in cases where ckpdb failed:
alterdb dbname -delete_invalid_ckp
Invalid checkpoints and associated journal and dump files are deleted. This command does not delete journal files unless they are for the oldest referenced and invalid checkpoint, so as to preserve the continuous journal sequence.
3. Delete all previous checkpoints by using the ckpd ‑d flag. Such a command may be useful on occasion:
ckpdb -d dbname
A checkpoint is taken and all previous checkpoint, journal, dump files, and configuration entries are deleted.