FALLBACK Protection and Physical Database Integrity
Fallback protection is another important data integrity mechanism. Fallback works by writing the same data to two different AMPs within a cluster. If the AMP that manages the primary copy of the data goes down, you can still access the fallback version from the other AMP.
Keep in mind that if you specify fallback for a table, you double the amount of disk space required to store the same quantity of data. The amount of disk space required by a table is also doubled if you configure your system for RAID1 mirroring. This means that if you configure your disk for RAID1 mirroring and also specify fallback protection for a table, you actually quadruple the amount of disk space required to store the same quantity of data.
Also be aware that when a table is defined with fallback, it imposes a performance penalty for all DELETE, INSERT, and UPDATE operations on the table because each such operation must be executed twice in order to update both the primary table and its fallback table.
The system defaults to bringing Teradata Database up when AMPs are down on the assumption that any down AMPs can run in fallback mode. If your site does not use fallback for its critical tables, you probably want to keep Teradata Database down in this situation. To enable the logic to keep Teradata Database down, you can use the Maximum Fatal AMPs option from the SCREEN command of the CTL DBS Control utility (see Utilities: Volume 1 (A-K) for documentation of the SCREEN command).
Teradata Database also provides a means for using fallback to deal with read errors caused by bad data blocks (see “About Reading or Repairing Data from Fallback” on page 672).