Can we modify Teradata Fastload parameters in parallel job?

[joeyfan]

I was looking at the Teradata Enterprise stage and the product documentation trying to find more about the Terasync table and how Fastload is invoked so we can write error-checking routines after loads.

In the Teradata Multiload stage I can define the names of the error tables. Because I know the table names I have the ability to write After steps that report any errors that occur based on the the presence of error tables. I would like to do the same process for Fastloads. Is there any way to accomplish this functionality in the Teradata Enterprise stage? Is there some trick to determining the cookie id in the Terasync table of the most recent run of a Fastload (because that cookie id is part of the error table name)? If not, does anyone have any error checking practices after Teradata Enterprise loads that you can discuss?

Thanks,
Adam

[ghila]

Adam,

We are using the TeraData Enterprise stage and we are facing the same problem. Usually the 2 error tables created by the Fastload are dropped. In case of a problem ( duplicate primary index key for example ), the error table #2 should be removed manually. The names of the two tables are ERR_cookie_1 and ERR_cookie_2. cookie is to be found on the terasync table. In that table, you may use starttime and endtime ( integer ) fields in order to help find the last ones inserted.
As far as I know, there is no way to modifiy the names of the error tables.

Can you check the DataStage patches installed on your server? We are on HP-UX 11.11 and DataStage patches exists. The behavior of the TeraData Enterprise stage may slighty be different depending of the patches installed.


Regards
Daniel

I was looking at the Teradata Enterprise stage and the product documentation trying to find more about the Terasync table and how Fastload is invoked so we can write error-checking routines after loads.

In the Teradata Multiload stage I can define the names of the error tables. Because I know the table names I have the ability to write After steps that report any errors that occur based on the the presence of error tables. I would like to do the same process for Fastloads. Is there any way to accomplish this functionality in the Teradata Enterprise stage? Is there some trick to determining the cookie id in the Terasync table of the most recent run of a Fastload (because that cookie id is part of the error table name)? If not, does anyone have any error checking practices after Teradata Enterprise loads that you can discuss?

Thanks,
Adam

[bcarlson]

We are using the TD Enterprise stage as well for a number of loads. At first, we were trying the MultiLoad stage, but ran into some issues with the length of our input records and with performance. We also ran into the same question about FastLoad parameter - or lack thereof.

After talking to both IBM/Ascential and Teradata, here's what we learned:

1) While the other stages may have more options, both Teradata and IBM recommended the Enterprise Stage. Like the other database stages, most noteably DB2, the Enterprise Stage is the one that is most actively supported and used the most efficient methods. The other stages use API calls and tend to not work as efficiently.

2) We were told that there are plans for adding options to the Enterprise stage so that more control is given back to the developer (like tenacity, sleep and table naming). ECASE 82946 has been opened to address some of these issues.

Brad.