If you have specified FALLBACK in creating the table, either explicitly or by default, the system automatically maintains a duplicate copy of the data in the table. This fallback copy is then used if the primary copy becomes unavailable.
Fallback is very important when a system needs to reconstruct data from fallback copies when a single-bit read error occurs when it attempts to read the primary copy of the data. When a hardware read error occurs in this case, the file system reads the fallback copy of the rows and reconstructs a memory-resident image of them on their home AMP. Without this feature, the file system fault isolation logic would abort the transaction and, depending on the error, possibly mark the table as being down. See SET DOWN and RESET DOWN Options.
- Requests that do not attempt to modify data in the bad data block
- Primary subtable data blocks
- Reading the fallback data in place of the primary data.
In some cases, Active Fallback can repair the damage to the primary data dynamically. In situations where the bad data block cannot be repaired, Read From Fallback substitutes an error-free fallback copy of the corrupt rows each time the read error occurs.
To avoid the overhead of this substitution, you must rebuild the primary copy of the data manually from the fallback copy using the Table Rebuild utility. For information about Table Rebuild, see Teradata Vantage™ - Database Utilities , B035-1102 .
To enable the file system to detect all hardware read errors for tables, set CHECKSUM to ON.
To create a fallback copy of a new table, specify the FALLBACK option in your CREATE TABLE statement. If there is to be no fallback copy of a new table in a database or user space for which FALLBACK is in effect, specify NO FALLBACK as part of the CREATE TABLE statement defining the table. Alternatively, if you want to accept the database or user default for fallback, do not specify the option for the table.