Considerations - TARA/ABU

Teradata Archive/Recovery Utility Reference

Product
TARA/ABU
Release Number
16.10
Published
May 2017
Language
English (United States)
Last Update
2018-05-01
dita:mapPath
utr1488824663491.ditamap
dita:ditavalPath
Audience_PDF_include.ditaval
dita:id
B035-2412
lifecycle
previous
Product Category
Teradata Tools and Utilities

Consider the following when archiving selected partitions in PPI tables:

  • A restore operation always deletes the selected partitions of the target table before restoring the rows that are stored in the archive.
  • Archiving selected partitions operates on complete partitions within tables, meaning that the selection of a partial partition implies the entire partition.
  • PPI and non-PPI tables are permissible in a single command. Both table types can be managed in a single database with the EXCLUDE TABLES option.
  • Partitioning is based on one or more columns specified in the table definition.
  • Partition elimination restricts a query to operating only in the set of partitions that are required for the query.
  • Incremental archives are possible by using a partition expression that is based on date fields, which indicate when a row is inserted or updated.
  • An archive or restore of selected partitions only places full-table HUT locks. HUT locks on individual partitions are not supported.
  • Re-collect table statistics after a restore of selected partitions. Statistics are part of the table dictionary rows, which are not restored during a partition-level restore.
  • If a table has a partitioning expression that is different from the partitioning expression used in the PPI archive, a PPI restore is possible as long as no other significant DDL changes are made to the table.

The archival of selected partitions has limitations. For more information, see Potential Data Risks When Archiving/Restoring Selected Partitions and Considerations Before Restoring Data.

The next example shows a partitioning expression that follows the PARTITION BY keyword. Data is partitioned for the TransactionHistory table, based on the month when the transaction occurred:

CREATE TABLE TransactionHistory
(TransactionID         INTEGER,
TransactionDate       DATE FORMAT ‘yyyy-mm’dd’,
TransactionParam1     INTEGER,
…
)
PRIMARY INDEX (TransactionID)
PARTITION BY RANGE_N
(TransactionDate BETWEEN DATE ‘2000-01-01’ AND DATE ‘2004-12-31’
EACH INTERVAL ‘1’ MONTH
);