TPT(teradata parallel transporter) error

ramesh_inform · Post by **ramesh_inform** » Tue Nov 11, 2008 2:22 am

we are doing a version migration as well as database migration in our project.
version migration is from 7.5.2 to 8.1
and database migration from DB2 to teradata

we exported our jobs in current environment and imported into new environment.
we changed our target DB2 stages to TPT stage

we sometimes encountered an error like "sync time out error" at the join stage. i could see records coming into reference link and main input link.

we tried giving different values to sync time out.
but resulted in the same error.

from the datastage manual i could see what sync timeout is
"Sync timeout Use this property to specify the maximum number of seconds to retry an update to the synchronization table."

we left the sync timeout value to default value.

we are using sync table and sync ID as well.
some of our developers are using the same sync table.
Is the above stated error related to sync time out options specified in TPT connector or because of different developers using the same sync table.?

hamzaqk · Post by **hamzaqk** » Tue Nov 11, 2008 3:30 am

well its def not due to different developers using the same sync table. is the sync ID unique for each combination of job and table? on what basis are you specifying this value ?

ramesh_inform · Post by **ramesh_inform** » Tue Nov 11, 2008 4:10 am

yes the sync table is one and the same. but we are using different sync ID's.

ramesh_inform · Post by **ramesh_inform** » Tue Nov 11, 2008 4:11 am

we are using different sync id's for different TPT stages and different jobs

toshea · Post by **toshea** » Tue Nov 11, 2008 2:05 pm

Check the DDL of the sync table and make sure that it has the following indexes:

PRIMARY INDEX ( SyncID )
UNIQUE INDEX ( SyncID ,PartitionNo ,StartTime )

If it doesn't have both indexes, you'll need to get the Teradata Connector patch for JR29504 and drop your old sync tables so that the connector will create them with the new indexes.

As a workaround, you can drop the old sync table and recreate it with the indexes yourself. Without both indexes, some of the connector's queries on the sync table may result in table scans. That could be the reason why your concurrent jobs that share the same sync table are interfering with each other even though they are using unique sync ID's. I am guessing that interference is why your jobs are getting sync timeouts. The default timeout is 20 seconds which should be long enough if jobs are not interfering with each other.