Teradata error (enterprise stage)

[bcarlson]

We are getting failed jobs with the error 'Error waiting for sessions." Has anyone seen that before from a Teradata database? The jobs pull either from files or datasets and just write to a Teradata table. It is about as simple as it can get. We are using the Teradata Enterprise stage to populate the tables.

Any ideas?

Brad.

[bcarlson]

Here's the log info:

Code: Select all

26  FATAL   Fri Jan  6 05:13:26 2006
    BTCAPIA1_Enterprise,13: session wait failed, return code = 220 (...)
27  FATAL   Fri Jan  6 05:13:26 2006
    BTCAPIA1_Enterprise,13: Error waiting for session. [terautils.C:901]
28  FATAL   Fri Jan  6 05:13:26 2006
    BTCAPIA1_Enterprise,13: Cannot write record. [terawriteop.C:1160]
29  FATAL   Fri Jan  6 05:13:26 2006
    BTCAPIA1_Enterprise,13: The runLocally() of the operator failed. [api/operator_rep.C:3990]

[mfortuna]

Apparently, Anything can be an issue with Teradata and EE. The EE engine is required to create tables before it can write the data in a EE job. The work around (if this is not allowed) is to create a tmp DB with full permissions, and set the following env vars accordingly:

APT_TERA_SYNC_USER
APT_TERA_SYNC_PASSWORD
APT_TERA_SYNC_DATABASE

Then we had another issue because of a C++ compiler incompatibility issue - check to make sure your c++ compiler is accurate to the lowest subrelease level with the admin doc for your OS.

Then there is a current outstanding issue, in which I am about to log a ticket (may be related to first issue above), where a user who is granted full access and control (admin) for a Database, still cannot access tables (read/write or drop/create) that he does not own, if the grants are not supplied at the table level. You can see the tables through Teradata utilities just fine, but not through Datastage. Apparently datastage only validates table level authentication, not DB level. Try checking the grant permissions for your tables.

Also check if you are extracting/ loading dates - we found yet another issue where Teradata does 4 byte date compression based on "some date 1970", but UV system dates are "some other date 1976" (or something to that effect). Don't accidentally write UV date types to teradata date types!!! You may do this and not even realize you corrupted all of your dates.

If you uncover another issue, please let me know. last thoughts:

try taking out any transforms or containers
try to read 1 record to a file- (set transaction size and commit size to 1)
try removing all date types except varchar - Teradata varchars are 2 bytes more than oracles, and dates and integers are more compressed.


Good Luck,

tuna

We are getting failed jobs with the error 'Error waiting for sessions." Has anyone seen that before from a Teradata database? The jobs pull either from files or datasets and just write to a Teradata table. It is about as simple as it can get. We are using the Teradata Enterprise stage to populate the tables.

Any ideas?

Brad.

[bcarlson]

I am not sure we are experiencing the same issues. We were able to run and test this just fine on our development system. Never once ran into this error in development and all testing came out okay (data was accurately represented in the target Teradata tables, including all dates). It was only when we installed to production that we started abending.

I am wondering if the problem is with our configuration. We are running from an ETL server with 16 nodes, connecting to a Teradata database with 12 nodes (124 AMPS). Our Teradata stages use the following options:

sessionsperplayer=2
requestedsessions=16

I have tried many other combinations for the parameters (1/8, 2/8, 2/16, 2/32, 4/32, 4/16, 4/64, etc.). In all cases, with all parameter combinations we get intermittent success and failure. Sometimes it works, sometimes it doesn't. The exact same configuration with work in one attempt and fail in the next. It does not appear to be connected to how busy Teradata is, we get the same results whether there are many other things running or nothing else at all (we have a lot of native non-DataStage apps running with MultiLoad, FastExport, and FastLoad).

Brad.