16.20 - Basics of Archiving Data - Teradata Vantage NewSQL Engine

Teradata Vantageā„¢ NewSQL Engine Node Software Migration Guide

prodname
Teradata Database
Teradata Vantage NewSQL Engine
vrm_release
16.20
created_date
March 2019
category
Administration
Configuration
Installation
featnum
B035-5942-162K

Archive 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, either 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.

Although you can use either DSA or ARC for the migration, ARC is a deprecated utility, and will not be supported in future releases.

Database DBC

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

Databases to Exclude

Some databases that are created by DIP scripts or replaced on a newer release should not be archived or restored. These include TD_SYSFNLIB, SYSBAR, SYSUIF, SYSLIB,CRASHDUMPS, and TD_SYSGPL. The CRASHDUMPS database contains system- and release-specific crash information that will not be relevant to the destination system, so it should also be excluded from the migration.

DSA will automatically exclude these databases, but if you use ARC, you must explicitly exclude TD_SYSFNLIB, SYSBAR, SYSUIF, CRASHDUMPS and TD_SYSGPL.

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 create a separate archive containing only the SYSLIB database and restores this database after database DBC and prior to any other user databases. After all other user data is restored, the DIP scripts ensure that the SYSLIB database is current.

The SYSSPATIAL database contains information about the geospatial data types.
  • If you were using non-Teradata geospatial data types on the source system, and wish to keep using those data types on the destination system, you should archive and restore this database.
  • If you were using non-Teradata geospatial data types on the source system, but want to use Teradata geospatial versions of the geospatial data types on the upgraded destination system, exclude SYSSPATIAL from the migration. The SYSSPATIAL database will be automatically created on the new system, and will contain definitions for the Teradata geospatial data types.

Archive Size

Teradata recommends breaking user data into multiple, smaller archives in preparation for a migration, rather than creating a single archive containing all databases. If an ARC restore job fails to complete due to an error, the entire job must be rerun. Otherwise, the databases that were successfully restored as part of this job will lose the statistics, and join and hash indexes for those databases. Statistics and hash and join indexes are processed during the build phase of the job and are kept in memory until the job is complete. If the restore job fails to complete, that information is lost unless the entire restore is started again.

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. 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 Teradata Vantageā„¢ NewSQL Engine Security Administration, B035-1100.

Source Data Preservation

As a precaution, keep the source system operational with the original data until you are certain that the destination system is running correctly with the migrated data.