Usage Notes - TARA/ABU

Teradata Archive/Recovery Utility Reference
Product
TARA/ABU
Release Number
15.00
Language
English (United States)
Last Update
2018-09-25
dita:id
B035-2412
lifecycle
previous
Product Category
Teradata Tools and Utilities

Usage Notes

Do not use database DBC as the target database name in a COPY statement. Use DBC as the source database in COPY FROM, but specify a target database name that is different than DBC. This allows DBC to be copied from a source system to a different database on a target system. When used as the source database in COPY FROM, database DBC is not linked to database SYSUDTLIB. Therefore, only database DBC is copied.

Do not use database SYSUDTLIB as the target database name in a COPY statement. Use SYSUDTLIB as the source database in COPY FROM, but specify a target database name that is different than SYSUDTLIB. This SYSUDTLIB to be copied from a source system to a different database on a target system. When used as the source database in COPY FROM, database SYSUDTLIB is not linked to database DBC. Therefore, only database SYSUDTLIB is copied.

Teradata ARC supports duplicate rows in a copy operation. However, if a restart occurs during the copy of a table with duplicate rows, the duplicate rows involved in the restart may be removed.

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.

COPY moves an archive copy of a database or table to a new environment. Copy options allow renaming archive databases or creating tables in existing databases. The table does not have to exist in the database it is being copied into. However, because the Teradata Database internal table identifier is different for the new table, access privileges for the table are not copied with the data.

When a database or table copies from an older version source system with a different configuration, it affects the time and space required to copy 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.

Do not copy a table name generated in a character set different from the default character set or the character set specified in the Teradata ARC invocation. For example, a table name from a multibyte character set archive cannot be copied into a single-byte character set database.

To work around this restriction:

1 ANALYZE the archive tape with the HEX runtime option specified.

2 Result: The table names are displayed in hexadecimal format (X’ C2C9C72A750A3AC5E4C5E4C36DD9D6E6)

3 Run the COPY table statements using the hexadecimal table names.

To copy more than one table or database with one COPY statement, separate the names with commas. Teradata ARC reads the archive data for each COPY statement it processes, therefore one COPY statement yields better performance than multiple COPY statements.

Example  

In the next example, the first table is copied to a different table name, and the next two tables are copied with the same table name.

   COPY DATA TABLES (test.test1) (FROM (oldtest.test1))
   ,(test2.test)
   ,(test3.test)
   ,RELEASE LOCK
   ,FILE = ARCHIVE;

If the configuration of the source and target platforms are different, copy cluster archives only to all AMPs or specific AMPs.

Use these options with all types of copy operations:

  • FROM (dbname.tablename)
  • RELEASE LOCK
  • NO BUILD
  • CLUSTER = nnn
  • AMP = n
  • FILE = name

    • These options are suitable only for data table copy operations, and only with dictionary and data table copies:

  • WITH JOURNAL TABLE (dbname.tablename)
  • NO FALLBACK
  • NO JOURNAL

    • Journal copy options are not supported after the target system is reconfigured. Journal table copy options define target (receiving) tables for change image journaling.

    Teradata ARC uses the journal table copy options to:

  • Select the set of journal images from an archive to copy.
  • Name the tables in the receiving system to which the images apply during rollforward or rollback operations.

    • When NO BUILD is specified, Teradata ARC leaves the restored journal in a prebuild state. Teradata ARC does not allow roll operations on journal tables in this state, and generates an error message if an attempt is made to roll this journal back or forward.

    If data tables are copied into a database that does not already have tables with those names, Teradata ARC creates the required tables. This is true only for data tables. Journal tables can never be created by a copy operation. They must exist in the receiving database. Similarly, do not create receiving databases with COPY.

    COPY preserves table names without converting them to upper case and returns these table names in their original format.

    Database DBC.DBCAssociation

    Teradata ARC creates a row in database DBC.DBCAssociation table for each dictionary row Teradata ARC copies successfully. This row contains columns with information that associate the copied table back to its originating Teradata Database.

    The row in database DBC.DBCAssociation also contains columns that link it to the TVM table, which associates the row to its receiving table, and to the DBase table, which associates the row to its receiving database.

    Teradata ARC also creates a column in each row of database DBC.DBCAssociation that links them to the RCEvent table. This link is the restore event number. For successful copy operations, the EventType in the RCEvent table is COPY.

    Locks

    COPY places exclusive client utility locks during its operations. If an entire database is copied from a full database archive, the entire database is locked for the duration of that operation. If a table level archive or a single table is copied, Teradata ARC locks only that table.

    Views, Macros, Stored Procedures, Triggers, UDFs, and UDTs

    Copying a full database archive is the same as a restore operation. Teradata ARC drops all existing objects and dictionary information in the receiving system. The data in the archive is then copied to the receiving database.

    However, triggers cannot be copied. If a trigger is defined in a database, <trigger> NOT COPIED is displayed when the COPY statement is processed. This is not an error or warning. Triggers must be manually recreated with SQL.

    If the views, stored procedures, and macros have embedded references to databases and objects that are not in the receiving environment, those views, stored procedures, and macros will not work. To make any such views, stored procedures, and macros work, recreate or copy the references to which they refer into the receiving database.

    If the views, stored procedures, and macros have embedded references to databases and objects that are in the receiving environment, they will work correctly.

    Note: Fully qualify all table, stored procedure, and view names in a macro and all table names in a view. Otherwise, an error can result. When COPY is used, partial names are fully qualified to the default database name. In some cases, this might be the name of the old database.

    Referential Integrity

    After an all-AMPs copy, copied tables do not have referential constraints. Referential constraints are not copied into the dictionary definition tables, database DBC.ReferencedTbls and database DBC.ReferencingTbls, for either a referenced (parent) or referencing (child) table copied into a Teradata Database. All referential index descriptors are deleted from the archived table header before it is inserted into the copied table.

    Reference constraints remain, however, on any table for which the copied table is a referenced table (a parent table) or any table the copied table (as a child table) references. Hence, when either a referenced or a referencing table is copied, the reference may be marked in the dictionary definition tables as inconsistent.

    While 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.

  • Use ALTER TABLE DROP INCONSISTENT REFERENCES to drop inconsistent references.
  • Use ALTER TABLE ADD CONSTRAINT FOREIGN KEY REFERENCES to add referential constraints to the copied table.

    • For an all-AMPs copy, REVALIDATE REFERENCES FOR is not applicable to COPY.

    Partial-AMPS Copy

    A Partial-AMPs copy occurs when copying with fewer streams in a multi-stream copy than were used in a multi-stream archive. For more information, see “Restoring with Partial-AMPs” on page 68.

    System Join Index Copy

    When using the COPY FROM syntax, System Join Indexes (SJIs) can now be copied to a different database. For more information, see “Copying System Join Indexes (SJIs)” on page 73 and “COPYSJI” on page 112.