Archiving the Data Dictionary - Teradata Database

Archiving the Data Dictionary

The Data Dictionary tables are maintained in the default database associated with system user DBC. This means that as they grow, they consume DBC permanent space, which is space also required by the TJ and other internal recovery journals. To protect your system software, you should archive the DBC database when:

A high volume of DDL statements has significantly increased the quantity of definitions for data tables, views, macros, indexes, triggers, stored procedures, roles, or profiles since your last DBC archive.

You plan to purge some dictionary logs that have grown very large due to a high volume of recorded activities, queries, or statistics.

You plan to upgrade your Teradata Database or migrate to a different platform.

The user may exclude tables being modified from the archive.

Note: When archiving partitions of the Data Dictionary you cannot specify the ALL PARTITIONS option.

Note: Embedded services function rows are not stored or copied when you execute BAR on system database TD_SYSFNLIB or on DBC dictionary tables. To reactivate embedded services functions, execute the DIPALL option.

For more information about archiving the Data Dictionary tables and a full list of the tables archived by the system, see Teradata Archive/Recovery Utility Reference.

If you are performing an archive or restore of a table or database using row-level security constraints, you must have the OVERRIDE DUMP CONSTRAINT and OVERRIDE RESTORE CONSTRAINT privileges in addition to the normal DUMP and RESTORE privileges.

If a RESTORE of a PPI row-level security table specifies the LOG WHERE option, it includes constraint columns in the resulting error table. Security constraints are not enforced for error row insertion, but are enforced for any subsequent access to the error table.

About Using COPY or RESTORE After a Constraint Change

Notice:

Do not change or delete values or value names in a constraint name:value pair if an archived table references the constraint. Row-level security of the table will be compromised if it is restored or copied from archive. Adding new valuename:value pairs to a constraint will not compromise the security of archived tables. For more information on row-level security and altering or dropping CONSTRAINT objects, see Security Administration.