Considerations Before Restoring Data
Before performing a restore operation, consider the following items. For a list of potential issues regarding the archiving of selected partitions, see “Potential Data Risks When Archiving/Restoring Selected Partitions” on page 38.
Dropped Database, Users, Tables, Views, and Macros
A restore of a database DBC drops all new databases or users created since the time the archive was created. Additionally, all new UDTs are dropped (because database SYSUDTLIB will also be restored with database DBC).
A restore of a user database drops any new objects created since the archive of the database. For a complete list of objects supported by Teradata ARC, see “Appendix A Database Objects” on page 261.
Restoring Undefined Tables with COPY
Do not restore a database or table to another system that does not contain an equivalent definition of the entity (for example, the same name and internal identifier).Otherwise, conflicting database and table internal identifiers can occur. To restore data tables that are not already defined in the data dictionary, use the COPY statement.
Insufficient Memory for Large Tables
Teradata ARC uses the same methodology as the Teradata SQL CREATE INDEX function to rebuild secondary table indexes. If there is insufficient available disk space, it might not be possible to restore a very large table because of the amount of temporary disk space that is required to recreate a secondary index.
Join and Hash Indexes in Restoring
Prior to Teradata Tools and Utilities 13.00.00
Teradata Archive/Recovery Utility does not archive or restore join indexes. If you attempt to restore a database containing a join index, the restore fails with DBS error 5468. If you attempt to restore an individual table which has a join index defined on it, the restore fails with DBS error 5467. This happens because the DBS does not allow deleting a database if it has a join index or a table with a join index defined on it. The DBS also does not allow deleting table with a join index defined on it.
To restore a database or a table with an associated join index from the archive file, you must manually drop all the join and hash indexes associated with the databases and tables being restored from the archive file before running the restore job. After the restore is completed recreate the join indexes.
To drop and recreate a join index
1 Extract the join index definition by executing a SHOW JOIN INDEX command and by saving the join index definition.
2 Drop the join index.
3 Restore the database or the table.
4 Recreate the join index by executing a CREATE JOIN INDEX command with the saved join index definition.
5 Collect the new statistics.
Teradata Tools and Utilities 13.00.00 and later
Beginning with Teradata Tools and Utilities 13.00.00, join and hash indexes can be archived and restored if these requirements are met:
Join and hash indexes cannot be restored from a pre-13.00.00 archive file because the indexes were not archived prior to 13.00.00.
When restoring a user table, any join and hash indexes defined in that table are automatically dropped prior to restoring the table. After the table is restored, the join and hash indexes are automatically recreated. The indexes are rebuilt from the archived definition if they do not currently exist on the system. If an archived join or hash index currently exists on the table, the existing definition is used to rebuild the join or hash index.
Individual join or hash index definitions can be restored by specifying the index name in the list of objects to restore.
When restoring a user table that has a join or hash index defined on it (or database containing such a table), the name of the user table or database must be specified in the RESTORE statement. If ALL FROM ARCHIVE is used to restore the table or database containing the user table with a join index, the job is aborted with a DBS error (error 5467 for a table and error 5468 for a database). This occurs because Teradata ARC is not given the name of the table or the database being restored and is therefore, unable to drop the associated join or hash index before restoring the table or database from the archive file. When using the ALL FROM ARCHIVE option, use the pre-TTU 13.0 procedure to drop manually all of the join and hash indexes associated with the databases and tables being restored from the archive file before running the job. See “To drop and recreate a join index” on page 51.
Restoring Join and Hash Indexes for a Cluster Archive
Join and hash indexes might not be recreated automatically when restoring a cluster archive because data in the base tables is not restored until all phases of the cluster restore are complete.
To restore join or hash indexes from a cluster archive:
During the dictionary restore, a warning appears for any join or hash indexes that could not be recreated.
Matching Hash Functions for Large Objects
Teradata ARC supports the restore operation for tables that contain large object columns as long as the database system is enabled for large object support. Starting with Teradata ARC 14.00, large object columns can be restored to a system that uses a hash function that is different from the one used for the archive.
Certain Statements Force the Restoration of the Entire Database
A Teradata SQL DROP or RENAME statement cause the definition of an entity to be removed from the dictionary. This same definition cannot be recreated using a Teradata SQL CREATE statement because a create operation is a new logical definition.
As a result, do not restore a dropped:
A Database DBC archive must also contain a definition of the dropped database.
Archive individual tables with care, and periodically archive the dictionary.
If restoring all of a user database or database DBC (that is, all of the Teradata Database) is required because of a catastrophic event, restore the dictionary information for the database at the database level before restoring the individual tables. Restoring the dictionary first restores the table definitions, so that the tables can be successfully restored.
Restoring/Copying NoPI Tables
When restoring/copying a No Primary Index (NoPI) table to a destination system that has a different number of AMPs than the source system, there is a high probability that the data will be skewed on the destination system after the restore/copy. This is due to the algorithm that is used by the DBS to distribute the data rows onto the AMPs for a NoPI table.