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:

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.

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.

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).

Add the following command after your routine checkpoint command:

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.

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.

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.

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.

Here are other commands for managing checkpoints and their associated files.