The restore/copy process for selected partitions creates Teradata-generated error tables. Rows are stored in error tables for the following reasons:
- A row that is in the range of selected partitions being restored fails the target table integrity checks
- A user does not want to restore a row but it satisfies the LOG WHERE condition
- An error occurs while evaluating these conditions for a row
The restore/copy process for selected partitions creates an error table with the characteristics listed below.
| Names | ||
| Database Name | If a database name is not specified (in the ERRORDB option or as a database qualifier of the error table name in the ERRORTABLES option), the error table resides in the same database as the target table being restored or copied. Otherwise, the error table resides in the specified database. | |
| Error Table Name | If the error table name is not specified (in the ERRORTABLES option), the error table has the name RS_targettablename truncated on the right as needed to 30 characters; if truncated, a warning message is issued. For example, if restoring table TB1, the default name for the error table is RS_TB1. |
|
| If a table has the same name as an existing error table in a database, an error occurs. Before the restore/copy job can be submitted, drop or rename this table, or specify another table or database name. Review the contents of the existing table to determine whether to drop it:
|
||
| Indexes | ||
| Primary Indexes | The primary index of an error table is non-unique and is not partitioned. The primary index columns are identical to the primary index columns of the target table. | |
| Secondary Indexes | An error table does not have any secondary indexes or participate in any referential integrity relationships. See Error Tables and Indexes for an example. |
|
| Restrictions for Error Tables | ||
| Do not share an error table between two or more restore/copy jobs. Each table targeted by a restore/copy job must have its own error table to ensure jobs run correctly. | ||
| Do not drop the error table until the restore/copy job finishes. The error table must not exist for non-restart of restore/copy job. It must already exist for a restart of restore/copy job. | ||
| Other Characteristics | ||
| Columns | All columns have the same data types and attributes as the target table except for column-level integrity constraints and not null attributes. | |
| DBCErrorCode | DBCErrorCode has INTEGER data type, not null. It indicates the Teradata error causing the row to be inserted into the error table. | |
| DBCOldROWID | DBCOldROWID has BYTE(10) data type, not null. It indicates the internal partition number, row hash, and row uniqueness value of the row at the time the backup was created. | |
| Empty Table | If the error table is empty when the restore/copy job for the target table finishes, it is dropped. | |
| No Constraints from Target Table | An error table does not have any of the NOT NULL, table-level, or column-level integrity constraints of the target table. This ensures that rows can be inserted into the error table that might fail the integrity constraints. | |
| Protection Type | An error table has the same FALLBACK or NO FALLBACK protection type as the associated target table. | |
| SET Table | An error table is always a SET table even if the target table is a MULTISET table. Duplicate rows are discarded. | |