Help! My Database is Corrupt

Help! My Database is Corrupt (and I don't have a Backup)

The real 'fix' for a corrupted database is to ensure that there is an effective backup scheme in use that will allow a recent copy to be restored. See Backing up a Database in the DP4 Developer's Guide for information on backup.

If a restore is not possible for some reason, and the problem can be shown to be in the index file only, the following steps may be taken to attempt recovery:

If the database has been improperly closed (system error 17) due, perhaps, to power failure, and there is not a valid roll-back file for any reason then run DBCHECK with the -pass, -check and -corrupt command tails to identify all problems. If errors are reported in the data file, then nothing further can be done to save the database without assistance from Itim Technology Solutions .
If DBCHECK does not indicate any problem with the data file, if there is a recent good copy of the index file, do as suggested in step 3 below. Otherwise remove the corrupt marker by patching the .ind file at offset 6C hex. Change the hexadecimal byte value 01 to 00. If the value is 02 see step 5. The successful running of DBCHECK in these circumstances merely indicates that the database is logically correct, not that there has not been a loss of data.
If DBCHECK indicates that the index file rather than the data file is faulty, (that is, the first error reported is in the index file), then REORGDB may be able to re-build it. The resultant database is 'suspect' and you should satisfy yourself that the data is in order. DYNACHEK can also be used where appropriate with the added advantage that it also checks that index entries match the records but it does not have a -corrupt or -pass command tail. Specify the -corrupt command tail when running REORGDB.
If for some reason an index file is lost or so corrupted that you cannot sensibly analyse the database using DBCHECK, make a new index file. Ideally this should be done by taking an old (the most recent good) copy of the index file. If this is not possible, copy bd.ind and rename it. Use of the base dictionary has the disadvantage that you lose collate sequences, generation number and other information stored in the index file, but it will still allow you to re-index your data. Try to rebuild this index file using REORGDB -corrupt -data -local (-local will speed up REORGDB if the database is on same machine). The Improperly Closed flag must be clear in the 'current' index file - see step 1 above. Itim Technology Solutions cannot guarantee the resultant database and the customer should satisfy themselves that the data is in order.
The procedures described in 2 and 3 should also be followed if you get a database corruption such as System error 87 caused solely by a problem in the Index file.
There is a peculiarity in DBRECOV which can cause problems if you try to recover a database by transferring the corrupt files to another machine or a fter changing the DFSETUP logging settings. If there is no .rlb file, but the database is still reported as being corrupt, you need to look at byte 6C in the index file.
- If this byte is 1 then the database is probably corrupt.
- If this byte is 2 then the database is in the state where the rollback file has been applied but not the .rll file. DBRECOV will recover the database in this state whether or not the .rll or .log file exist, but only if the DFSETUP transaction log settings are the same as they were when the crash took place.
  This is because, when the corrupt flag is 2, DBRECOV inspects flags in the database header that indicate whether a .rll or .log file should exist according to the DFSETUP settings for transaction logging as currently perceived by the database manager. If you transfer a database from a machine with transaction logging off to one where it is on, DBRECOV will not recover it properly - it will test the 'log started' flag, see that it is FALSE and give up. Renaming the .rll file to .log will have no effect, nor will deleting it, the only way to get the DBRECOV to complete is to turn transaction logging off in DFSETUP, and reload the database manager. Exactly the same thing would happen if you transferred a corrupt database from a machine with transaction logging on to one where it was off. DBRECOV would not work until you turned logging on.

Notes on Logging

The idea of DBRECOV and the Roll-back log is to enable, after a power failure crash, a quick restart (together with information from the current Transaction log) using the current index and data (hard disk) files without the need to revert to the previous back-ups held on floppy/tape.

Disabling transaction logging is not recommended because all transactions since last backup will be lost in the event of unrecoverable corruption. These logs can be made to floppy if the appropriate option is selected with DFSETUP, but this would not be recommended as suitable for customer site operation. Ideally the transaction log should not be on the same disk as the database because this will give some added data security if one disk is damaged.

If roll-back logging is disabled, the only means of safely recovering the database, in the event of a system crash when the database was not closed, is to restore it from a back-up. If transaction logging is disabled a .rll temporary pseudo transaction log is created, in parallel with .rlb to permit database recovery to occur.

The transaction log has the same name as the database with a .log extension. The roll-back log has the same name with the extension .rlb. This is normally deleted, as is the .rll file, after a set number of commits occur or when exit from DP4 occurs normally.

Disaster Recovery assistance from Itim Technology Solutions

If the data file is corrupt, the only possible solution is for the database to be sent to Itim Technology Solutions where an engineer can use some internal tools and attempt to patch out corrupted records. These tools are not documented, nor are they designed for end-user use. Certain corruptions require modifications to these tools, or manual repairs to data. It should be noted that any work done to attempt such a recovery is outside of our standard support contract, so chargeable, and it is also stressed that this will only be done on a 'no liability' basis, which means the possible resultant database has no guarantee whatsoever.