|
|
|
Checkpoints provide you with a snapshot of the database at the time you took the checkpoint.
Each time you perform this operation, a new checkpoint of the database is taken.
A record of up to 99 checkpoints can be maintained at any point. We recommend that at least one database-level checkpoint be included in this record.
The use of the Database Infodb menu command to verify the status of the database and checkpoints is encouraged. This ensures that a valid database checkpoint is always available.
Running a checkpoint does not affect the current state of journaling for the database. For details on how to enable and disable journaling with a checkpoint, see Database Journaling and Disable Journaling.
Tables that have had journaling enabled after the previous checkpoint have their journaling status changed from "enabled after next checkpoint" to just "enabled."
To checkpoint a database or tables, you must be a privileged user (operator privilege or system administrator). For more information, see the chapter "Ensuring Access Security."
|
|
|
In VDBA, you can create a new checkpoint for a database by using the Checkpoint dialog, invoked by the Database Checkpoint menu command.
The detailed steps for performing this procedure can be found in the Procedures section of online help for VDBA. See Checkpoints.
You can also accomplish this task using the ckpdb system command. For more information, see the Command Reference Guide.
|
|
|
You should use table-level checkpoints only as a supplement to—not a substitute for—database-level checkpoints.
|
|
|
Use caution in the area of table-level checkpoints and recovery. Generally, full database checkpoints are recommended over table-level checkpoints. When using table-level checkpoints and restores, it is important—at the very least—to back up all dependent tables with a full checkpoint.
Table-level checkpoints are restricted in their recoverability when the checkpointed table has been dropped or the table has been modified through any DDL statement. In these cases, the table-level checkpoint is rendered unusable. There is also danger in compromising the referential integrity of the database when rolling forward a table without journaling.
Performing table-level checkpoints on system catalogs is not permitted. Frequent database checkpointing of the iidbdb database is strongly encouraged.
|
|
|
Whenever a database is rolled forward, it is recommended that a new checkpoint be taken to allow subsequent table-level roll forward activities.
When a roll forward is performed at the table level, you can choose either to roll forward the table excluding or including all secondary indexes. You cannot specify a secondary index name as a table.
If it is necessary to do a roll forward with the No Secondary Index option, the base table's secondary index in the RDF cache become inconsistent. To clear the inconsistency, do one of the following:
If additional assistance is required, call Ingres Technical Support.
|
|
|
A file called the checkpoint template file, cktmpl.def, drives the checkpoint and roll forward operations. The cktmpl.def file allows you to customize backup and recovery processes and provides additional information tracking. It is possible to modify the backup process so that the names of the tables that are specified during a table-level backup are written to a text file.
The II_CKTMPL_FILE environment variable overrides the default cktmpl.def file for a particular user. This must be used when testing modifications to the cktmpl.def file before it is made available to the entire installation so that other users in the installation are not affected.
For checkpoint template codes and parameters, see Checkpoint Template File Description.
|
|
|
Checkpoints can be performed online or offline.
|
|
|
An online checkpoint can be performed while sessions are connected to the database. This is the default when taking a checkpoint.
An online checkpoint stalls until any transactions running against the database are committed. Any new transactions started during the stall phase of the online checkpoint cannot run until the stall phase is completed.
|
|
|
An offline checkpoint can be performed when no one is using the database. To perform an offline checkpoint in VDBA, enable the Exclusive Lock checkbox in the Checkpoint dialog.
When you specify the Exclusive Lock option, you can also specify the Wait option to wait for the database to be free before performing the checkpoint.
The behavior with or without the Wait option specified is described as follows:
|
|
|
By default, an exclusive lock is not taken on the database when you take a checkpoint. Other users who are using the database at the time of the checkpoint can continue working online. During this time, transactions in progress are placed in the dump file for the database.
When you perform a roll forward, the dump files are used to restore the database to its state when the checkpoint was taken. It updates the database from journals, if the database is journaled.
There are two cases, however, in which checkpointing takes an exclusive database lock. These are if either of the following options in the Checkpoint dialog are used:
If you want to continue the present journaling status, use neither journaling option.
|
|
|
After you take a new checkpoint, you can delete previous checkpoints and journals.
|
|
|
In VDBA, specify the Delete Previous option in the Checkpoint dialog.
Up to 98 checkpoints can be deleted in this way.
|
|
|
If you have taken more than 98 checkpoints after the last time you created a checkpoint with the Delete Previous option in VDBA, you must delete the additional old checkpoints manually using a system command.
Observe the following cautions when manually deleting checkpoints:
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:
C000v00l.ckp
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. To obtain this number, select the database and choose the Infodb command from the Database menu. View the information in the Infodb dialog.
|
|
|
To delete old checkpoints manually, use an operating system command, as follows:
Windows: Use the Windows del command from the II_CHECKPOINT\ingres\ckp\dbname directory.
UNIX: Use the UNIX 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.
VMS: Use the VMS delete command.
|
|
|
You can delete the oldest available full database checkpoint, along with associated journal and dump files, by enabling the Delete Oldest Checkpoint check box in the Database Characteristics dialog, invoked by the Operations Alter DB menu command in VDBA.
This option operates only for full database checkpoints, not partial checkpoints. For more information about the Database Characteristics dialog, see Database Characteristics.
|
|
|
You can delete invalid checkpoints, along with associated journal and dump files, by enabling the Delete Invalid Checkpoint check box in the Database Characteristics dialog, invoked by the Operations Alter DB menu command in VDBA.
This option operates only for full database checkpoints, not partial checkpoints.
For more information about the alterdb command, see the Command Reference Guide.
|
|
|
Important! A checkpoint is a backup of an existing database. If you destroy the database (with the Edit Drop menu command), you cannot recreate it from a checkpoint, because this deletes a database's associated checkpoints as well.
To destroy your database and recreate it, use the Unloaddb menu command, appearing off the Database Generate Scripts submenu. For more information, see the chapter "Loading and Unloading Databases."
|
|
|
In UNIX, you can checkpoint to a disk or a tape in parallel.
|
|
|
To checkpoint a multi-location database to disk in parallel, issue the ckpdb command with the #m flag followed by the number of parallel checkpoints to be run. For example, to save two data locations at a time to the II_CHECKPOINT location, the command is as follows:
ckpdb \#m2 dbname
|
|
|
To checkpoint a multi-location database to tape in parallel, in the Checkpoint dialog, specify multiple table devices to be used in the Tape Device edit control. For example, enter the following:
/dev/rmt/0m,/dev/rmt/1m
This saves one location per tape—the first location can be stored on device 0m; the second on device 1M. The third location can be stored on whichever device is finished first. The remaining locations can be stored on the next free device. The operator is prompted to insert a new tape for each location.
When performing parallel checkpointing to tape in UNIX, keep in mind the following:
|
|
|
In Windows, the backup system uses the Windows backup utility to create checkpoints on tape. This utility allows you to back up on multiple tapes. The program prompts you for more tapes as needed during the checkpoint procedure.
The backup uses the commands in the following batch file:
%II_SYSTEM%\ingres\bin\ckcopyt.bat
You can tailor these commands to meet your needs (for example, to meet local conventions such as tape labeling).
For detailed information on backing up to tape, please see your Windows documentation on backup utilities.
|
|
|
In UNIX, the backup system uses an operating system utility, such as tar (Berkeley UNIX) or cpio (System V), to create checkpoints. Both cpio and tar are limited to handling files that fit on a single tape. Because checkpoints of larger databases abort at the end of the first tape, you must estimate both the checkpoint size and the tape capacity before checkpointing these databases. If you estimate that the checkpoint exceeds the tape size, follow instructions in Checkpointing to Multiple Tapes in UNIX.
|
|
|
A separate checkpoint file is created for each location to which a database has been extended.
Follow these steps to estimate the size of checkpoint files:
du ii_database/ingres/data/default/dbname
where ii_database is the value of the environment variable II_DATABASE displayed by the ingprenv command.
For other locations, substitute the name of the directory associated with the location name.
For information on the number of bytes in a block on your system, see your operating system manual.
|
|
|
The capacity of a tape depends on the following:
Standard 9-track tape drives write at either 800, 1600, or 6250 bits per inch (bpi), so the bits per inch specification is the same as bytes per inch. The standard tape length is 2400 feet.
Block sizes, which are not standardized, are important because of what is between the blocks—the IRG. A typical IRG is .75 inches of empty tape separating each block from the next.
|
|
|
You can use the following formula to estimate the size of the file in bytes that a tape can accommodate:
F = (B + (I * D))/(12 * B * D * L)
where:
The sample file sizes in the following table were calculated for a standard 2400 foot tape, assuming an IRG of .75:
Tape Size |
IRG |
Block Size |
Density |
File Size (MB) |
|---|---|---|---|---|
2400 |
.75 |
512 |
1600 |
13.8 |
2400 |
.75 |
512 |
6250 |
17.7 |
2400 |
.75 |
8192 |
1600 |
40.2 |
2400 |
.75 |
8192 |
6250 |
114.5 |
After using this formula to calculate the file size, you need to add an arbitrary amount to allow for miscalculations. You do not want a tape to run off the reel because you miscalculated the size of the file that fits. A reasonable amount to add is 5% of a tape's capacity.
If your system uses a cartridge tape or other storage media, contact the vendor for the specifications that allow you to make the calculations described above.
|
|
|
To checkpoint a database to a single tape:
The equivalent ckpdb command at the operating system prompt is as follows with a tape drive named "/dev/rmt8":
ckpdb -m/dev/rmt8 dbname
The backup created by this checkpoint writes over everything that was on the tape previously.
|
|
|
When checkpoint files exceed the tape size, follow the appropriate procedure depending on whether the file fits on a disk.
|
|
|
If the checkpoint file exceeds the size of the tape, but fits on a disk, follow these steps:
If some of the database's tables are stored in alternate locations, separate checkpoint files are created for them in the checkpoint location. These files are small enough to be moves to single tapes.
Caution! To System V Users: It is possible for large checkpoints to exceed the ulimit on your system. (The ulimit is a tunable operating system parameter that sets a limit on file size.)
|
|
|
If the checkpoint file exceeds the size of the tape and does not fit on a disk, you must checkpoint the database using the operating system. To successfully checkpoint a database, you have to lock all users out during the entire process.
To lock out all users and take the checkpoint, follow this procedure:
The Wait option causes the checkpointing to wait until all user locks have been released before beginning the checkpoint.
The Delete Previous option removes all previous checkpoints and journals.
The Tape Device specification causes the checkpoint to be placed in /dev/null, which is a nonexistent device. This makes the database "think" it is being checkpointed and causes journaling to be correctly synchronized. At this time, all changes to the database are guaranteed to be on disk.
C shell:
After the first message from the checkpoint is printed, press Ctrl+Z.
Bourne shell:
Log in at another terminal immediately after the checkpoint begins.
Start the new process by issuing the following command at the operating system prompt:
ingres -l +w dbname
The +w flag causes a wait until that lock is granted.
C shell:
If the checkpoint process is stopped (csh job control), put the job back in the foreground; wait for the process to complete.
Bourne shell:
Wait for the process to complete.
Make sure that the backup method used allows you to save the files and recover them to their original places on the system. Some backup methods have limitations. The volcopy command, for instance, requires that the database disk device be unmounted and unavailable for use by any users during the copy. Additionally, it saves files by saving the entire file system.
Leave the second process stopped (csh).
For the Bourne shell:
Leave the second process at the SQL prompt (*) until the backup is complete.
|
|
|
To initiate a checkpoint in VMS, ready the tape and issue the ckpdb command with the –m option. For more information about the ckpdb command, see the Command Reference Guide.
The backup system uses the VMS BACKUP utility to create checkpoints. This utility allows you to back up on multiple tapes. The program asks for more tapes as needed during the checkpoint procedure.
The backup uses the following command in the script:
II_SYSTEM:[INGRES.FILES.CHECKPOINT]CKP_TO_TAPE.COM
You can tailor this command to meet your needs (for example, to meet local conventions such as tape labeling).
For detailed information on backing up to tape, see your VMS backup documentation.