This article provides a high-level overview of the process involved in moving to Teradata 13. Teradata 13 offers many new features and some of the highlights are covered in other articles on DEV/X. The focus here is how to get to Teradata 13.0.
Note: You should install, upgrade, migrate, and back down Teradata Database only with the assistance of qualified Teradata field personnel. Contact your sales or customer support representative (CSR) to initiate all IUM activities.
The first question to ask yourself when planning a move to Teradata 13.0 is what release and platform do you have now and what is your target.
How you get to Teradata 13.0 depends largely on whether you’re on V2R5.x or a prior release, or onV2R6.x or later release. In this article, these are referred to as Type I and Type II respectively as illustrated below.
Also, the migration process also depends on whether you intend to move to a new Teradata hardware platform, change the operating system that you’re running on the Teradata nodes, or remain on your current platform.
There are two options for moving from one release of Teradata to another – Upgrade and Migration.
Upgrades can move up only one release level at a time, for example V2R5.x to V2R6.x. Upgrades are typically used for release level changes across major, minor, maintenance or patch releases.
Migrations, on the other hand, can move up to two major release levels at a time, for example V2R5.x to TD12.0. They are also used when moving to a different platform such as a 64-bit system from a earlier generation of Teradata hardware and operating system support. A migration requires that you store data on media (exception is NPARC migration done by Teradata Operational Services).
Data Migrations are typically used migrate data to move it to a newer or larger destination system. But with a migration, you can also move up in Teradata Database release level by up to two major releases, compared to moving up only one major release by a software upgrade. You accomplish the two-level jump on a single system using a “migration in place” process that includes:
• archiving the data -- On a migration, the data is archived from the system,
• installing the newer Teradata Database release on the system, complete with sysinit
• restoring the data -- the data is restored (and any migration scripts run) to either the same system or an entirely new system, the later being the most typical usage of migration. If it’s a new system, the data must be redistributed among the new set of AMPS.
Upgrading is the process of replacing an earlier release of Teradata Database software -- only one major release -- with a more recent release. The user data remains, and is converted, in place on the disk arrays. The system hardware does not change in any way.
Upgrading from Release V2R6.x to Release 12.0 is a major upgrade that includes a data
conversion. The upgrade changes the Teradata Database system tables to the Unicode data format.
It is possible to use the upgrade process to move from a release older than one major release, but special requirements apply. For example, an upgrade to Release 13.0 from V2R5.1.2 and previous releases requires a multi-stage implementation to facilitate the data conversion necessary for moving through intermediate releases.
To facilitate this, all customers upgrading to Release 13.0 from Teradata V2r6.2 or older releases will automatically receive a copy of the intermediate versions of Teradata Database – in this case Teradata 12.0 (specifically 184.108.40.206 ) -- to use during the multi-stage upgrade process. Any 6.x customer can upgrade to 220.127.116.11 and then to 13.0 (i.e. 6.0 or 6.1 can upgrade to 12.0 and bypass 6.2 since that is still only one major release upgrade). This additional CD is labeled according to the operating system on which Teradata Database is running, and is for upgrade purposes only.
Customers are licensed to use the interim software CD only as part of the upgrade process. After the upgrade is complete, customers should dispose of the CD. If the CD is not required because the customer is upgrading from a newer Teradata Database version, it should be disposed of immediately.
With past Teradata releases, the release of the Teradata Tools and Utilities (TTU) needed to be equivalent or greater than that of the Teradata Database. For example, if you were on release Teradata 12.0 of the database, you needed to be on TTU 12 or TTU 13. You could not be on a prior release of TTU. Thus, in most cases, you would upgrade you TTU release and then your database. This is still the recommended approach; however, with Teradata 13.0, this has changed. Teradata 13.0 supports TTU 12.0 and TTU 13.0. The reason for this is to provide more flexibility in how you upgrade your Teradata environment.
The following applies to this new feature:
• The following TTU 12.0 products will work with Teradata 13.0, but will not expose or work when used with new DBS features: APIs (ODBC, CLI, JDBC, etc), Load/unload (Fastload, Multiload, Fastexport, tpump, TPT), plus BTEQ & SQL Assistant.
• There are several products for which this new compatibility feature does not work. For the following TTU products, they will need to be upgraded when Teradata is upgraded: Back & Recovery (BAR / aka ARC), Teradata Manager, TDWM (Basically all workload management / database management products), Query Director, MDS.
• It is also to point out that products from TTU 12.0 do not support the new features in the Teradata 13.0 database.
Referring to the Type I – customers on Teradata V2R5.x and Prior – and Type II – customers on V2R6.x and later – from earlier in the article, the following illustrates the required step for moving to Teradata 13.0 in the various scenarios.
I am thinking that you should rearch out to your Teradata site team to request the Ghost patch. We have certified the Ghost fix for 13.10 and updated TSS with the certified packages. We are recommending all customers pick up the Ghost patch.
we are upgrading from 14 to 15 its a new appliance, new system is connected to exsting BAR solution . data migration either we run restore jobs or TPTS. how to migrate the views, macros and storeprocedures into new system.
Please provide your inputs
when we restore DBC data into new system, databases/schemas and users will be covered in that or do we need to create the schemas manullay ?.