Strategy for Dropping Error Tables
Use the default Teradata PT behavior, that is, the automatic creation and dropping
of error tables, except as follows:
Set the DropErrorTable attribute to No, to retain the error tables if:
The job is new and you are not sure it will run correctly. Then you can use the retained
error tables, even if the job completes with an exit code of 0 or 4, to evaluate how
the job ran and whether or not you need to revise the job script to make it run better.
Once the job runs successfully several times you can reset DropErrorTable to Yes.
The operator ErrorLimit attribute is set to a value greater than 0. This setting means
that any errors that the job encounters will be loaded into the error table. Especially
for jobs with high error limits, the job is not really complete until you can examine
the errors and determine whether or not further action is required, so the error tables
should be retained.
The job is a batch job run repeatedly at close intervals, such as “Job Example 8: Batch Directory Scan” on page 111. The job may run several times before you have time to evaluate the error tables,
so they should be retained for evaluation.
Note: Set the Stream operator AppendErrorTable attribute to allow successive runs of the
job to write to the same error table.
If error tables are retained and the Stream operator AppendErrorTable attribute is not in force, you
must manually drop the error tables before the next run of the job, using a DROP TABLE
statement.
Some jobs, such as “Job Example 9: Active Directory Scan” on page 112, run continuously for the duration of the value of the VigilElapsedTime attribute,
and will not drop error tables until the end of that elapsed time. This may result
in the following problems, for which you must prepare:
High-volume jobs with large error limits may overrun the space allocation for the
error tables. If this happens you need to either increase the space allocation, or
set the elapsed time to a shorter duration. It may be useful to periodically save
the error tables to an alternate location to allow time for evaluation.
Jobs containing operators with high values for the ErrorLimit attribute may accumulate
a large number of bad rows. Make sure to set the DropErrorTable attribute to No so the error tables will be retained at the end of the VigilElapsedTime, to allow
time for manual processing of the bad rows. Make sure to manually drop the error tables
before the next run, or set the AppendErrorTable attribute to Yes.