Checking the Database Integrity

Checking the integrity of a database can take some time. For a database containing several gigabytes of data, you may wish to run the check overnight. (If you want to check the database while it is on line, see Checking the Database Integrity Dynamically )

1. On the Database Integrity Checking menu, select option 3 - Integrity check. DP4 displays status messages as it checks the database integrity:
   
   The number of records and index nodes counted is also displayed

   At any time, you may interrupt the integrity check with <Ctrl+S> and <Ctrl+C> or <Ctrl+Alt+Del> without corrupting the database

2. If the database passes the integrity check, the following message is displayed:
   

   If the database fails the integrity check, a message is displayed to identify the problem area:

   • If the message indicates a problem with the index, then you may be able to re-generate the index file using the database reorganisation utility (see Reorganising with Compression). However, if you have followed proper backup procedures you will probably find it quicker, and less risky to restore a backup copy of the database and apply the transaction log.
   • If the message indicates a problem with the data file, then you will need to retrieve a backup copy of the database and apply the transaction log to roll-forward the database, as described in Restoring a Database.
     
     

   In the event of a database being corrupt, and a good backup not being available technical staff at Itim Technology Solutions will attempt to repair the database if it is supplied on Tape or CD-ROM. This is not covered by your support agreement, and we reserve the right to charge for this work.

Performing Additional Checks on Consistency Using -full

Up to release 4.622 DBCHECK performs only rudimentary tests of the relative consistency of the data and index files - it only checks that each index entry points to a record of the correct type, not that the index entry actually matches the data in the record. Rarely a database might have a corruption of this type. As of release 4.623, by specifying the command fail -full you can force DBCHECK to perform this type of checking, which was previously only available in DYNACHEK.

When you use this option DBCHECK calculates a 32 bit CRC for every index entry, and when the data is accessed compares this CRC with the CRC of the corresponding data. This increases the time needed for checking the database by a considerable amount, though exactly how much will depend on the number of records in each table and the number of secondary indexes. The increase is greater for a database using advanced compression (and for these databases corruptions of this type caused by a low level error in the data would almost always show up as a data file corruption). However, even with full checking the time taken to check a database is not that great - perhaps 12-15 minutes per gigabyte of data, or twice that if the database has advanced compression, compared with around 5 minutes per giagabyte for the less thorough check performed when you do not specify -full.

The checking performed by DBCHECK -full is not quite as exhaustive as the checking in DYNACHEK: because the validation of the index entry is done using a CRC, there is a very slight possibility that a corruption might not be detected.