15.10 - Accessing and Using Error Tables - Parallel Transporter

Teradata Parallel Transporter User Guide

prodname
Parallel Transporter
vrm_release
15.10
category
User Guide
featnum
B035-2445-035K

Error tables are automatically generated for the Load, Stream, and Update operators in a Teradata PT job, to provide information on Teradata Database errors encountered while writing data to the Teradata Database. Error tables provide more detailed information about errors initially presented in the job logs. Error tables segregate errors into two groups:

  • ErrorTable1 (Acquisition Error Table) - Reports constraint violations, bad data, and data conversion errors.
  • Error Table2 (Application Error Table) - Contains any rows that cause violations of the unique primary index, for instance duplicate rows. This error table is not used when the target table has a non-unique primary index.
  • The following operators support error tables:

     

    Operator

    Description

    Load

    Generates acquisition and application error tables (ErrorTable1 and ErrorTable2).

    Error tables are named in one of the following two ways:

  • The operator automatically names the table in terms of the target table, as follows:
  • For ErrorTable1: TargetTableName_ET
  • For Errortable2: TargetTableName_UV
  • The ErrorTable1 and ErrorTable2 attributes name error tables.
  • Update

    Stream

    Generates only an acquisition error table (ErrorTable), which is equivalent to ErrorTable1. The Stream operator places the table in the database associated with the job script user logon.

    The error table is named in one of the following two ways:

  • Use the ErrorTable attribute to name the error table.
  • You can also prefix the name with a database name if the table is to be stored in a different database than the one that contains the target table, using the form:

    DatabaseName.ErrorTableName

    For information chapters on the Load and Update operators in Teradata Parallel Transporter Reference.

  • If no name is specified for the ErrorTable attribute the operator automatically names the error table, for instance: M<yy><doy>_<seconds>_<LSN>_ET
  • where:

  • M is the default prefix
  • <yy> is the last two digits of the year
  • <doy> is the day of the year
  • <seconds> is the seconds of the day
  • <LSN> is the logical session number
  • ET is the default suffix (meaning “error table”)
  • Note: Teradata recommends that you do not use this default error table name. It is a large character string that may lead to data entry errors when accessing the table.

    The content and format of error tables is different for each of these operators. For detailed information the sections beginning with “Load Operator Errors” on page 184.

    Consider the following facts about error tables:

  • If a job generates no errors, the error tables are empty. They are automatically dropped at the end of the job, unless the DropTable attribute is set to No.
  • If errors are generated, error tables are retained at the end of a job.
  • To rerun jobs from the beginning, either delete the associated error tables or rename them, otherwise an error message results, stating that the error tables already exist.
  • Conversely, to restart a job from a step or checkpoint, an error table must already exist. Do not delete error tables until you are sure you will not have to restart the job.
  • To reuse names specified for error tables, use the DROP TABLE statement in the BTEQ utility or the DDL operator to remove the tables from the Teradata Database.