As it applies to ISAM files, file corruption (error 22) occurs when the control information in an index file doesn’t correspond to the records in the data file, the data records have been corrupted, or the index is corrupted. File corruption can be detected by running the isutl -v utility and corrected by running the isutl -r utility. When corruption in the data partition is detected, isutl may fail, usually with a BADSEG error, and you will be prompted to run isutl again with the -a option. Isutl -r (and the automatic resilient recovery) attempts to create a valid index without the need to immediately use -ra, so the system can be used more quickly and the data recovery (-ra) can occur at the next maintenance window. Any records that cannot be processed by isutl -ra will be written to an exception file with the extension .exc.
The RESILIENT option allows Synergy DBMS to detect file header corruption (i.e., the index file header and data file header are out of sync). This is usually the result of killing a program or shutting a system down during an ISAM store, write, or delete operation or failure to write the operating system cache out to disk on a fatal system crash. RESILIENT does not detect data file or index corruption due to failing hardware.
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, and the chances are even better when compression is used in conjunction with SGRFA. This is because the codes used to compress the data (or generate the GRFA) 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.
