About Reading or Repairing Data from Fallback
When the file system detects a hardware read error (see “Conditions That Support Reading or Repairing Data from Fallback”), the AMP that owns the bad data block sends a message to each of the other AMPs in its cluster. This message contains the tableID and rowID range of the unreadable data block. Each of the other AMPs in the cluster then reads its fallback rows in that range and sends them to the requesting AMP. There, the rows from each AMP 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: Volume 2 (L-Z). 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” on page 666).