All Forums Tools
chill3che 99 posts Joined 10/12
30 Jul 2013
Mload through Informatica - errorlimit, errorcode 6705, restore tgt table if auxiliary table dropped in application phase

Greetings Experts,
We are using some jobs that use Mload connection in Informatica.  If the number of rows in ET table is >= errorlimit specified, will the session be forced to fail?

We have a job which is often failing with "External Loader Error" and we could see the presence of the rows in ET table with error code 6705 on a column "abc". I have used the translate_check on the column "abc" and got a row that has a null value for the column "abc".  The data is same in both PROD and QA for the column "abc". But not sure why it is failing in QA and not in PROD. I know that it's hard to go with this little info. Does some other settings may be different that might be the case, if so, can you please name them.

How is control file generated through Informatica?  Is it through the API on Teradata side?

Say if one of the Auxiliary tables be dropped accidentally on a Mload target table (Not staging table) in the Application phase, it is not possible to re-start or re-run the job.  Can it restored to its original form by using the before Permanent journal if enabled?  If it is not, how can we restore the table to its original state if the backup copy is out of date to that of current data (say 2-3 days, every day there are major changes)

Thank you for your values insights.

Thanks, Cheeli
Ivyuan 63 posts Joined 01/10
14 Aug 2013

Hi Cheeli,
Yes, MultiLoad will termiante if error limit exceeds. 
Please check the column definition of the column "abc" in the target table and/or the user default charset set on the server was the same in both QA and PROD, which might help pinpoint why TD error 6705 sometimes showed up.
The control file should be on Informatica side.
Teradata MultiLoad creates four tables that are required for restarting a paused Teradata
MultiLoad job:
• Restart Log Table
• Work Table
• Acquisition Error Table
• Application Error Table
If any of these tables are dropped while a Teradata MultiLoad job is paused, restarting the job
normally is not an option, and the target tables can be left corrupted.
In some limited circumstances, restart such a job using special procedures is possible but, in
most cases, do not drop these tables for a paused job without careful analysis of the situation.
The following topics describe the operational implications of having dropped the required
restart tables for a paused Teradata MultiLoad job.

Refer to Chapter 2 (Implications of Dropping Required Teradata MultiLoad-Created Tables) in Teradata MultiLoad Reference for further information:

You must sign in to leave a comment.