Strategy for Dropping Error Tables - Parallel Transporter

Teradata® Parallel Transporter User Guide - 17.20

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
Lake
VMware
Product
Parallel Transporter
Release Number
17.20
Published
June 2022
Language
English (United States)
Last Update
2023-08-25
dita:mapPath
uzp1645128359760.ditamap
dita:ditavalPath
tvt1507315030722.ditaval
dita:id
B035-2445
Product Category
Teradata Tools and Utilities

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. The job may run several times before you have time to evaluate the error tables, so they should be retained for evaluation.
      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, run continuously for the duration of the value of the VigiElapsedTime 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.