Kbase 20397: What Cannot be Repaired when the BI File is Corrupted
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
03/05/2011 |
|
SUMMARY:
This solution discusses repair options for a corrupted before-image (BI) file.
EXPLANATION:
When the BI file is corrupted and cannot be used, it is sometimes recommended that you can force in, do an index rebuild, and schedule a dump and load. But this does not guarantee to get database back to normal.
An index rebuild recreates all the index blocks. The rebuild repairs an index that is corrupted (for example, when an index block split occurs and one side of the split is lost). However, you also might have corrupted records.
For example, assume you have a record that is composed of two fragments that are stored in different blocks. When such a record is updated, the two blocks that contain the fragments are each updated. It is possible that one of the blocks was written to disk but not the other.
Crash recovery takes care of this situation and redoes the lost update to the other block. If you skip crash recovery, it is possible for the record to be smashed because you have one new fragment and one old one. Records are fragmented without regard to field boundaries, so the split can occur in the middle of a field. A dump and load fixes whatever can be salvaged, but there is no way to recover the broken record(s).
Another instance where you might still have logical inconsistencies is where you have an order-line without an order. This inconsistency might still remain after a dump and load if there is no trigger that checks whether a no order-line can be inserted for an nonexistent order.