Database Validation

Firebird and InterBase® databases are renowned for their stability. However there are a few things that could potentially lead to problems. Database validation involves checking the database file to ensure that the various data structures retain their integrity and internal consistency. The validation process checks for three different types of problems:

Corrupt data structures: for example, if a database row spans more than one page and the pointer that links the first page to the second is damaged or missing, there is a corrupt data structure. Firebird/InterBase® is able to correct this situation, but the damaged row might be lost. Misallocated data pages: for example, a page can be used for transaction inventory, header information, data, blob pointers, or indices. If a page has been flagged as one type, but actually stores data of another type, Firebird/InterBase® detects the problem. However Firebird/InterBase® cannot recover from this type of problem, so it will probably be necessary to restore from a backup. Orphaned data pages, which are automatically returned to the free space pool. By default, Firebird/InterBase® does not completely fill data pages with records, to allow space for new records to be quickly inserted. As records are added and deleted, some pages are likely to end up with no active records on them. Older Firebird/InterBase® versions do not automatically reallocate these pages to the free space pool. The IBExpert Database Validation menu item offers those options also available in the Firebird/InterBase® GFIX.

It is advisable to back up the database before validating. If possible it should also be shut down, so that the backup can be restored if necessary without any loss of transactions which may have been performed since the backup.

The Database Validation menu item can be found in the IBExpert Services menu. It enables the database to be validated and verifies the integrity of data structures.

Before starting the validation process you need to close the connection to the database with IBExpert (right click Disconnect… in the DB Explorer tree) as Firebird/InterBase® needs exclusive access to a database for fixing any errors. Select the registered database to be validated. The following options are none other than the GFIX parameters and may be specified as wished:

Limbo Transactions: If this option is checked, the database is checked for transactions in limbo, i.e. transactions, that can't be defined as executed or aborted. Please refer to Transactions in limbo for further information. Check Database: This option validates the database, but doesn't repair it. Ignore Checksums: This option ignores all checksum errors. A checksum is a page-by-page analysis of data to verify its integrity. A bad checksum means that a database page has been randomly overwritten (for example, due to a system crash). Kill Shadows: This option kills all unavailable shadow files. Mend Database: This prepares a corrupt database for backup and repairs any database corruption if possible. Sweep Database: This option can be checked to perform a database sweep (see database sweep for more information about sweeps). Validate Database: (default value). This option validates the database structure. Validate Full: This validates record fragments. Note: This feature is not available in InterBase® versions older than the version 6. Output: Check Verbose to receive an extended report about the current database validation process. Select whether this report should be displayed on screen or saved to file (not forgetting of course to specify drive, path and file name). Then start the database validation using the green arrow icon or [F9]. You will be asked to log in

before the validation is started.

Output

If no corruption is detected, a message is displayed informing that no database validation errors were detected. If corruption is detected that can be repaired, a report is displayed showing the number and types of errors found. Note that sometimes irreparable database corruption is found, such as damage to the database header or space allocation tables.

Please refer to Database Corruption for further information concerning the recovery of corrupt databases.