Database SYSUDTLIB is linked with database DBC and is only restored if DBC is restored. SYSUDTLIB cannot be specified as an individual object in a RESTORE statement.
If database DBC is involved in a restore operation, it is always restored first, followed by database SYSUDTLIB. If additional databases are being restored, they follow SYSUDTLIB in alphabetical order.
An all-AMPs restore or a specific AMP restore can use archive files created by any of the following:
During a restore of a Teradata Database, Teradata ARC issues messages in the following format as it restores different types of objects:
"UDFname" - n,nnn,nnn BYTES, n,nnn,nnn ROWS RESTORED
"procedurename" - n,nnn,nnn BYTES, n,nnn,nnn ROWS RESTORED
"macroname" - MACRO RESTORED
"methodname" - METHOD RESTORED
"methodname" - n,nnn,nnn BYTES, n,nnn,nnn ROWS RESTORED
"tablename" - n,nnn,nnn BYTES, n,nnn,nnn ROWS RESTORED
"triggername" - TRIGGER RESTORED
"UDTname" - TYPE RESTORED
"viewname" - VIEW RESTORED
When all tables are restored, Teradata ARC issues this message:
STATEMENT COMPLETED
At the start of a restore, or after a system restart, all offline AMPs are listed in the output log.
After each restore, compare the contents of the output log with listings of tables that were restored to determine which tables were not restored to offline AMPs.
Teradata ARC supports duplicate rows in a restore operation. However, if a restart occurs during the restore of a table with duplicate rows, the duplicate rows involved in the restart might be removed.
When a database or table restores from an older version source system with a different configuration, it affects the time and space required to restore data to the destination system. The data must be redistributed among the new set of AMPs. The system uses a different algorithm to copy and restore when the number of AMPs is different between the source and destination systems. This new algorithm is usually faster when the configurations are different. The old algorithm may be faster in some restricted situations.
Unique secondary indexes are distributed across all AMPs. Therefore, RESTORE does not rebuild unique secondary indexes, even if the indexes are in a cluster that is not being restored. Use the BUILD statement to build and revalidate unique indexes.
All-AMP Restores
If an archive file from an all-AMPs archive is used for an all-AMPs restore of data tables, Teradata ARC deletes the current copy of the data tables being restored before it restores the archive copy.
Cluster AMP Restores
When restoring a cluster archive to a reconfigured system, run the cluster archives serially. If this restore scenario is detected by ARCMAIN, the NO BUILD option is automatically enabled, if not specified, and an explicit BUILD command must be run after all restore jobs are completed.
When using NO BUILD for a cluster restore operation, submit an all-AMPs BUILD statement after all the clusters are restored. Do not use the NO BUILD keywords for fallback table cluster restore operations. If a cluster loses an AMP before the all-AMPs build, restore that cluster manually.
If an archive file from a cluster archive for an all-AMPs restore of data tables is used, a dictionary restore must precede the all-AMPs data tables restore.
Do not access fallback tables until a build operation is completed. Do not update non-fallback tables until a build operation is completed.
Specific-AMP Restores
Use the specific-AMP restore to restore non-fallback data tables. Only perform this recovery when the AMP to be restored is online to normal Teradata Database operations. If an archive file from a specific-AMP archive is used, Teradata ARC does not delete the current copy of any non-fallback table being restored before it restores the archive copy.
If one or more AMPs are offline during archive or restore, it might be necessary to perform specific-AMP restores after completing an all-AMPs or cluster restore. For example, if an AMP is online at the start of a restore and goes offline during the process, it might be necessary to restore some non-fallback tables to the AMP when it comes back online. If, however, an AMP is offline at the start of a restore and comes back online before the procedure completes, Teradata ARC restores subsequent non-fallback tables to the AMP. In either case, specify the NO FALLBACK TABLES option of RESTORE.
Partial-AMPs Restores
A Partial-AMPs restore occurs when restoring with fewer streams in a multi-stream restore than were used in a multi-stream archive. For a discussion regarding Partial-AMPs restore, see “Restoring with Partial-AMPs” on page 73.
Journal Table Restores
Restore dictionary definitions of the journal tables with the RESTORE DICTIONARY statement against a journal archive. This creates empty journal tables.
If archive data sets containing journal tables are concatenated by some operation outside of the Teradata Database, subsequent journal tables are not accessed from the concatenation by the restore process.
Restore the definition of the journal table to a reconfigured system by performing a DICTIONARY RESTORE from an all-AMPs journal archive.
Table Restores
When restoring an entire table, restore an all-AMPs archive before any specific-AMP archive files. If restoring a single AMP from a disk failure, use the specific‑AMP archive. Table restores accomplish the following:
Dictionary Table Restores
An all-AMPs dictionary tables restore must precede cluster restores involving fallback tables. A DICTIONARY restore leaves all fallback tables recovered in a state of restoring and leaves all indexes invalidated for non-fallback tables.
Restoring After a Disk Failure
To recover from a disk failure, run the Disk Copy and Table Rebuild utilities to restore database DBC and all user data tables defined with the fallback option, then perform a specific AMP restore.
To specify the non-fallback tables that were not restored while the AMP was inoperative, specify database names or names of individual tables with the EXCLUDE keyword.
When restoring part of a non-fallback table during an all-AMPs restore is not possible because an AMP is offline, the system invalidates unique secondary indexes for the table. After the AMP is back online and the table has been restored, either drop and then recreate the unique secondary indexes for the table, or use BUILD to recreate secondary indexes.
To restore from a catastrophic condition (for example, to restore database DBC) on a system that has permanent journaling, restore the system using an archive created from an ARCHIVE JOURNAL TABLES statement in the following order:
1 RESTORE DATA TABLES (DBC) ...;
2 RESTORE DICTIONARY TABLES (DBC) ALL, EXCLUDE (DBC), (TD_SYSFNLIB)..., FILE=ARCHIVE;
Note: For this example, ARCHIVE is a journal archive.
3 ;RESTORE DATA TABLES (DBC) ALL, EXCLUDE (DBC), (TD_SYSFNLIB)...;
4 RESTORE JOURNAL TABLES (DBC) ALL, EXCLUDE (DBC), (TD_SYSFNLIB);
Note: Follow Step 4 only if rolling the journal images forward or backward.
RESTORE builds the fallback copy of primary and non-unique secondary index subtables within a cluster. If the system fails during this process, RESTORE rebuilds fallback copies automatically.
Referential Integrity
When a table is restored into a Teradata Database, the dictionary definition of that table is also restored. The dictionary definitions of both the referenced (parent) and referencing (child) table contain the complete definition of a reference.
Nonetheless, in restoring tables creating an inconsistent reference definition in the Teradata Database can happen. Hence, when either a referenced (parent) or a referencing (child) table is restored, the reference might be marked in the dictionary definition tables as inconsistent.
When a table is marked as inconsistent with respect to referential integrity, no updates, inserts or deletes are permitted. The table is fully usable only when the inconsistencies are resolved.
If inconsistent constraints remain after a REVALIDATE REFERENCES FOR statement has been executed, use ALTER TABLE DROP INCONSISTENT REFERENCES to remove inconsistent constraints.