Executing Partial Table Copies with Teradata Data Mover

In the last Teradata Data Mover (TDM) article (Introduction to Teradata Data Mover: Create your first job), we discussed creating and executing a TDM job to copy a full table between Teradata systems. This use case is very common in the field when customers want to initially populate the target Teradata system with the same table that exists on the source Teradata system. Customers will not want to copy the entire table to the target system every time changes are made to the source system though. Tables on production systems can get quite large and it doesn't make sense to copy the entire table when only a subset of rows have been changed since the last copy took place. This is why TDM supports executing partial table copies as well as full table copies.

This article will discuss how customers typically use TDM to copy recent source table changes to the target system by executing partial table copies.

Determine What Changes Need To Be Copied

TDM only copies objects when told to do so by the user (either through the TDM command-line interface or the Viewpoint portlet). TDM does NOT automatically detect when changes have been made to the source system and then copy those changes to the target system. As a result of this, users must tell TDM what part of the table needs to be copied if they don't want the entire table copied in the job. Determining what changes have been made to a table can be complicated, but most customers accomplish this by maintaining a date/timestamp or batch id column in their source tables to track when changes have occurred.

Create a Partial Copy TDM Job

Let's use the same jg185041.items1 table we created in the Introduction to Teradata Data Mover: Create your first job article to create a partial copy TDM job. In this example, let's assume we want to copy all rows that correspond to when sales were made after 2009. This of course assumes that the date values in the table reflect when the row was updated and the sale was made. Here is the XML file we will use to create a TDM job that will copy all rows corresponding to sales made after 2009:

As you can see in the XML file above, the <sql_where_clause> and <key_column> tags are used to tell TDM that this is a partial table copy job. TDM will pass the where clause statement as-is to the underlying utility used to extract the data and then it will transfer only those extracted rows to the target table. TDM will also create the target table if it doesn't already exist prior to copying the data. If the target table already exists and has rows in it then TDM will copy the data to a staging table first before using merge or insert-select to get the data from the staging table to the target table. The key columns specified in the job will be used in the merge or insert-select statement to uniquely identify the rows that need to be updated in the target table. Specifying the proper key columns is required so that TDM only updates the appropriate rows in the target table.

You can see in the status output that only 19 rows were copied in this job instead of the full 200 in the source table. You can also see that ARC was used to execute this partial table copy. This might seem strange, but ARC can actually be used to execute partial table copies when PPI tables are specified in the TDM job. TDM will use TPTAPI or JDBC to execute partial table copies in all other cases though.

The next TDM article will discuss how to execute dynamic partial table copies with TDM.

Re: Executing Partial Table Copies with Teradata Data Mover

Is it possible to copy a table partially using ARC when it's having a Identity Column.

And my second question would be my partial job is failing the Row Count Validation. As it was comparing the row count on target side with where caluse on target sides control date can't it check the source control date.

Re: Executing Partial Table Copies with Teradata Data Mover

Hi gannu,

Yes, you should be able to do a partial table copy with ARC as long as the table being copied is a PPI table.

The partial row count validation will compare the results of executing a "select count(*)" on the source and target tables using the where clause provided in the job definition. If the where clause contains a nested table that isn't the same on the source and target (assuming the control date is in a different table than the one being copied) then the validation could fail. Copying the nested table specified in the where clause to the target system might resolve this issue.

Please refer to the Data Mover User Guide for more information on both of these topics if necessary.

Re: Executing Partial Table Copies with Teradata Data Mover

It seems like you're hitting the DBS bug covered in DR 156160. This bug happens in the DBS when using export without spool with certain types of nested select statements. Using export without spool is the default for Data Mover TPTAPI jobs because it increases performance. You should upgrade the DBS to a version that has the fix for DR 156160 to resolve this issue. If upgrading the DBS isn't an option then you can set <export_without_spool> to false in the Data Mover job for all tables that encounter this problem as a workaround.