As it applies to ISAM files, file corruption occurs when the control information in an index file doesn’t correspond to the records in the data file. Data corruption occurs when records in the data file have been unexpectedly overwritten or inserted. File corruption can be detected by running the isutl -v utility and corrected by running the isutl -r utility. When data corruption is detected, isutl fails, usually with a BADSEG error, and the file remains undisturbed. You will be prompted to run isutl again with the -a option. Any records that cannot be processed will be written to an exception file with the extension .exc.
Recovery options and strategies
When recovering data from a corrupted ISAM file, we recommend you first copy the ISAM file (both .ism and .is1). Then, if recovery should fail with one method, you can try other methods.
The file with the highest chances for recovery from data corruption is a file that employs data compression. This is because the codes used to compress the data can also be used as a roadmap to distinguish between good data and data corruption. If one or more data records near the beginning of a file are corrupted, isutl can skip them (these bad record segments are automatically sent to the exception file as they are found in the data file) and continue recovering the rest of the file. You may be able to reconstruct the lost records by examining the exception file.
|
The exception file is a counted file and the data written is a copy of the binary data segment exactly as it was in the data file. You can use fconvert to convert the counted file to something easier to work with. |
It is more difficult to attempt recovery from data corruption on files without data compression. Isutl may detect data corruption in files with variable-length records, but the only thing it can do is to write the rest of the data file to the exception file. If the index file is in good shape (with at least one good key), you may recover more data by using fconvert to recover the file.
|
|
When running isutl -v on a file with corrupted data, look for keys displaying fewer index related errors or data pointer errors. |
Files with fixed-length records and no data compression make detecting data corruption most difficult. The data retrieved from the data file is whatever happens to be at the stored location. If one record gets written with the wrong size, every record after it will be at the wrong file boundary. This phenomenon has been know to happen during system crashes and other abnormal terminations. Previous versions of Synergy ISAM continued storing records and making index links to new records, and the file continued to operate as normal. Ismvfy detected the problem, but irecovr wasn’t able to recover from it. The current version of Synergy ISAM checks record boundaries before it writes data. If an invalid boundary is detected, an error is produced, and you cannot extend the file by adding records to it until you recover the file using isutl.
