I am using Teradata connector with Bulk/Update using Parallel Syncronization on a 8 node Grid config. The job is some times failing with following error:
"Sync timeout of 200 seconds expired while waiting for the other instances to reach state 9,000 (CC_TeraAdapter::waitForState, file CC_TeraAdapter.cpp, line 5,816)"
When I looked at the sync table (created by Datastage job). it has primary index: SyncID and Uniqu Secondary Index: SyncID, PartitionNo, StartTime.
This sync table is standalone specific to this job.
Interestingly when ever the job fails with Sync timeout error, every time the Partition number =0 is in controlstate of 1006 and all other remaining 7 partitions in controlstate of 9000.
Please suggest what may be going wrong. At this point of time I am not sure if it is Datastage or Teradata.
Thanks.
Teradata Connector TPT- Sync Timeout errors
Moderators: chulett, rschirm, roy
-
Chandrathdsx
- Participant
- Posts: 59
- Joined: Sat Jul 05, 2008 11:32 am
We have run into this many times and there are many different things to consider.
First of all, IBM had suggested a minimum standard of 300 seconds for sync timeouts. also, make sure this is a parameter that can easily be updated. Depending on the volumes you are reading/writing and how busy your database is when this job needs to run, you may need to consider longer timeouts. We have a parm called ds_td_sync_timeout in the job and it is assigned a value from the Unix environment (small is 300 seconds, and large is 1000 seconds).
Another thing to look at the overall performance of your job. You could be timing out because the code feeding the load is inefficient. More often than not, this was actually the cause of our issues. We have rarely had to use the large sync timeout setting. We could avoid it by tuning the overall job performance.
Hope this helps.
Brad.
First of all, IBM had suggested a minimum standard of 300 seconds for sync timeouts. also, make sure this is a parameter that can easily be updated. Depending on the volumes you are reading/writing and how busy your database is when this job needs to run, you may need to consider longer timeouts. We have a parm called ds_td_sync_timeout in the job and it is assigned a value from the Unix environment (small is 300 seconds, and large is 1000 seconds).
Another thing to look at the overall performance of your job. You could be timing out because the code feeding the load is inefficient. More often than not, this was actually the cause of our issues. We have rarely had to use the large sync timeout setting. We could avoid it by tuning the overall job performance.
Hope this helps.
Brad.
It is not that I am addicted to coffee, it's just that I need it to survive.
-
Chandrathdsx
- Participant
- Posts: 59
- Joined: Sat Jul 05, 2008 11:32 am
Thank you for your valuable inputs. My job is tuned to perform optimally. The issue with sync-timeout happening more often when there is huge data to be processed and almost every time the partition 0 is not reaching the approriate status. I tried with max sync time out of 600. Is there any other soln apart from increasing the sync timeout thru parameter? The reason is I want all players/partitions to go with same speed and I can't afford to wait for a process/partition to reach approriate state for 1000secs or so as performance is very critical for the jobs we are doing.
Thanks again for you suggestion, please throw some more light in this regard
Thanks.
Chandra.
Thanks again for you suggestion, please throw some more light in this regard
Thanks.
Chandra.