15.10 - Recovering a Failed Update Operator - Parallel Transporter

Teradata Parallel Transporter User Guide

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

Recovering a Failed Update Operator

A failure can happen in these stages of the Update operator job:

  • Before the acquisition phase
  • During the acquisition phase
  • During the application phase
  • After the application phase
  • Before the Acquisition Phase

    Before the acquisition phase, the Update operator does the following:

  • Verifies the value of the attributes in the job
  • Logs onto the Teradata Database
  • Sends the command to the Teradata Database to create the work table(s)
  • Sends the DML statement(s) to the Teradata Database
  • Corrective Action: The TPT job displays the error message. Correct the error and resubmit the job.

    During the Acquisition or Application Phase

    During the acquisition phase, the Update operator does the following:

  • Sends the command to the Teradata Database to start the acquisition phase
  • Sends data to the Teradata Database. The data is loaded into the work table(s)
  • Sends the command to the Teradata Database to end the acquisition phase
  • In the acquisition phase, the Teradata Database puts MultiLoad locks on the target table(s).

    During the application phase, the Update operator does the following:

  • Sends the command to the Teradata Database to start the application phase
  • Sends the command to the Teradata Database to end the application phase
  • In the application phase, the Teradata Database performs the DML statement(s) on the target table(s) using the work table(s). When the application phase is complete, the Teradata Database releases the locks on the target table(s).

    When a failure occurs in the acquisition or application phase, the load is in the paused state. A paused state means the Teradata Database is waiting for the load to be restarted after the failure is fixed. The target table(s) can be accessed when the failure occurred in the acquisition phase; it cannot be accessed when the failure occurred in the application phase.

    Corrective Action: The TPT job will display the error message. Correct the error and resubmit the job.

    If you are unable to correct the error and you want the load to get out of the paused state, follow these steps:

    1 Use a utility such as BTEQ.

    2 Log onto the Teradata Database.

    3 Enter these commands in the specified sequence:

    RELEASE MLOAD <Target Table 1>;
    DROP TABLE <Work Table 1>;
    DROP TABLE <Error Table 1>;
    DROP TABLE <Error Table 2>;
    DROP TABLE <Log Table>;

    The target table name, work table name, error table names, and log table name are in the original load job that failed.

    The RELEASE MLOAD command releases the MultiLoad locks on the target table.

    If the original load job has more than one target table, repeat the commands in step 3 for the other target table(s), work table(s), and error table(s).

    You need to drop the log table only once.

    Note: The user should not drop the target table(s) unless they know what they are doing. The TPT Update operator is typically used to load populated tables. If the user drops the target table(s), they could lose a lot of valuable data.

    4 Verify the target table(s) can be selected.

    Use a utility such as BTEQ to select the target table(s).

    Here is a sample request to select the target table:

    SELECT COUNT(*) FROM <MyTargetTable>;

    You should get the row count, which means the load is no longer in the paused state.

    The result should not return the following Teradata Database error:

    RDBMS 2652: Operation not allowed: <table name> is begin Loaded

    If the original load job has more than one target table, repeat the sample request for the other target table(s)

    After the Application Phase

    After the application phase, the Update operator does the following:

    Drops the work table(s), error tables and log table, unless the user requested not to drop them

  • Logs off the sessions from the Teradata Database
  • Corrective Action:

    1 Use a utility such as BTEQ to drop the work table(s), error tables or log table. Skip this step if the user did not request to drop them.

    2 If the sessions remain on the Teradata Database, ask the system administrator to delete the sessions; or, wait for 20 minutes. After 20 minutes, the sessions are logged off by the Teradata Database Gateway.

    You do not need to resubmit the job.