We are in the process of setting up a new server for DS v8. This is our SIT environment. It has the same version of AIX, DS v8 (and patches), Teradata utilities, etc. and talks to the same database. About the only differnence (that I know of) is the number of players in the config (2 nodes vs. 4 in dev).
The same job works fine in dev, but is failing in this new environment. I am getting the following sync timeout issue:
td_shaw_acct_trnsl,7: [IIS-CONN-TERA-005024] Sync timeout of 300 seconds expired while waiting for the master instance to update the TELINFO area (CC_TeraAdapter::selectTELINFO, file CC_TeraAdapter.cpp, line 6,546) [pxbridge.C:2833]
We have had other sync timeouts, but with different messages. I haven't seen one with this 'master instance' or TELINFO reference before. Any idea what this is?
Thanks!
Brad.
It is not that I am addicted to coffee, it's just that I need it to survive.
I would like to know about this error message "Sync timeout of 300 seconds expired while waiting for the " and how it got resolved.
Appreciate any insights.
DS uses a sync table in Teradata to manage all of its sessions that it is running on the database. DS attempts to sync all of the sessions and will timeout if one or more sessions cannot be sync'd within a given time N, where N is the Sync Timeout option in the Connector.
By default, the timeout is 20 seconds. IBM told us that is way too short, and recommended 300 secs as the standard, then increase as needed. We use small, medium and large timeouts of 300, 1000 and 1500, respectively.
The timeout can be for many different reasons, some avoidable, some not:
1. Teradata database is under heavy load
2. ETL server is under heavy load and cannot read fast enough or cannot write fast enough to keep sessions in sync
3. SQL query to retrieve data has not been tuned and has poor perfomance and cannot retrieve data fast enough.
4. ETL process that writes the data to Teradata is ineffcient and does not write data fast enough.
There may be other reasons, but those are the most commons reasons we found. Items 1 and 2 are more related to load balancing and may or may not be within the control of the developers to fix. On the other hand, items 3 and 4 are fixable. For #3, either your developer or DBA should be able to tune your SQL queries to make them as efficient as possible. For #4, look to IBM best practices to make sure your DS job that processes the data and wries to Teradata is as efficient as possible.
Hope this helps.
Brad.
It is not that I am addicted to coffee, it's just that I need it to survive.
