When the file system detects a hardware read error, the AMP that owns the bad data block sends a message to the AMP that stores its fallback data. This message contains the tableID and rowID range of the unreadable data block. The fallback AMP reads its fallback rows in that range and sends them to the requesting AMP. There, the rows are reconstructed as a valid data block that can be used instead of the unreadable data block. In some cases, the system can repair the damage to the primary data dynamically. In other cases, attempts to modify rows in the bad data block fail. Instead, the system substitutes an error-free fallback copy of the corrupt rows each time the read error occurs.
To avoid the continued overhead of data block substitution when dynamic repair cannot be performed, rebuild the primary copy of table data manually from the fallback copy using the Table Rebuild utility. For details, see Utilities. You cannot use Table Rebuild to rebuild a hash index, join index, or USI, so if the corruption occurs in a hash index, join index, or USI subtable, you must drop the index and recreate it.
To detect all such read errors, the integrity checking level for the table or index should be set to ALL (see Disk I/O Integrity Checking).
Conditions That Support Reading or Repairing Data from Fallback
Reading or repairing data from fallback is limited to the following table, subtable, and data block types:
- Hashed tables.
- Primary hash index, join index, and USI subtable data blocks.
Reading or repairing data from fallback cannot be done for the following table types:
- Unhashed tables.
- BLOB, CLOB, or XML subtables.
- NUSI subtables, whether their parent table is defined with fallback or not.
Reading or repairing data from fallback can only be used when:
- All AMPs in the fallback cluster are up.
- Requests do not try to modify the data in the bad data block.