Reading or Repairing Data from Fallback | VantageCloud Lake - Reading or Repairing Data from Fallback - Teradata VantageCloud Lake

Lake - Database Reference

Deployment
VantageCloud
Edition
Lake
Product
Teradata VantageCloud Lake
Release Number
Published
February 2025
ft:locale
en-US
ft:lastEdition
2025-11-21
dita:mapPath
ohi1683672393549.ditamap
dita:ditavalPath
pny1626732985837.ditaval
dita:id
ohi1683672393549

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 those rows to the requesting AMP. There, the rows are reconstructed as a valid data block that can be used instead of the unreadable data block. The system may be able to repair the damage to the primary data dynamically. If not, attempts to modify rows in the bad data block fail, and the system substitutes an error-free fallback copy of the corrupt rows each time the read error occurs.

To detect all such read errors, the integrity checking level for the table or index must 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 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 compute cluster are up.
  • Requests do not try to modify the data in the bad data block.