Data Archival Basics - Teradata Database

Teradata Database Node Software Migration Guide

Product
Teradata Database
Release Number
15.10
Published
November 2017
Language
English (United States)
Last Update
2018-04-25
dita:mapPath
heq1467819788761.ditamap
dita:ditavalPath
5942_Migrating_1510.ditaval.ditaval
dita:id
B035-5942
lifecycle
previous
Product Category
Software

Archival Mechanisms

For migrations from Linux systems running Teradata Database releases earlier than 14.10 or from non-Linux systems, the ARC utility in conjunction with BAR application software must be used to archive data; otherwise, the DSA or the ARC utility can be used.
The ARC utility and BAR software can co-exist with DSA on the same BAR hardware. However, ARC software restores only from ARC archives, and DSA restores only from DSA archives.

Archival Process Overview

When migrating a full system, you must first archive database DBC followed by all user databases and objects from the source system.

Some databases that are created by DIP scripts or replaced on a newer release should not be archived or restored. When archiving user data, you must exclude databases DBC and TD_SYSFNLIB. It is also recommended that you exclude CRASHDUMPS, SYSLIB, and SYSSPATIAL.

SYSLIB database contains the GetTimeZoneDisplacement and algorithmic compression UDFs that may be referenced during the restoration process. If user databases contain algorithmic compressed data, you must restore SYSLIB database after restoring DBC database and running the post_dbc_restore script, and before restoring any other user databases. You can create a separate archive containing only SYSLIB database for this purpose. After all other user data is restored, the DIP scripts ensure that the SYSLIB database is current.

Archive Size

If the destination system has insufficient space for a database, the restoration of that database fails. Additional space must be given to the database on the destination system before the database can be restored successfully. In addition, other databases included in the same restoration job that were successfully restored prior to running out of space must be restored again in order to migrate the statistics, join indexes and hash indexes. Statistics, join indexes, and hash indexes are processed during the build phase of the restoration process, and the information is kept in memory. If the restoration job fails to complete, that information is lost unless the entire restoration job is restarted. For this reason, breaking user data into multiple smaller archives in preparation for migration is recommended over creating a single archive containing all databases.

Secure Zones

Teradata Database Release 15.10 introduced the Secure Zones feature, which allows creation of one or more separate and exclusive database hierarchies, called zones, within a single Teradata Database system. Access and administration for each zone is handled separately from the Teradata Database system and from other zones.

Only the owner of a Secure Zone can archive or restore databases within that zone, and that owner cannot be DBC. Therefore, beginning with Teradata Database Release 15.10, each Secure Zone owner must create archive and restore jobs for the databases in their respective zones in order to perform a full-system migration. For more information, see Security Administration, B035-1100.

Source Data Preservation

It is a good practice to keep the source system operational with the original data until you are certain that the destination system and data are running correctly.

If you are upgrading your source system to become your destination system, you should preserve the archived data media until you are certain that the destination system is running correctly.