The following table describes the things to consider when using the BEGIN MLOAD and BEGIN DELETE MLOAD commands.
|Database and Table Name Specifications||If the work table or error table names are not specified, Teradata MultiLoad creates them using the target table or view names with a three-character prefix of WT_, ET_, or UV_, as in:
Do not share the work and error tables between two or more Teradata MultiLoad jobs. Do not share work and error tables between two or more target tables in a single Teradata MultiLoad job. Each table targeted by a Teradata MultiLoad job must have its own work and error tables to ensure that the job runs correctly.
If a distinct work and error table are not used for each table targeted by a Teradata MultiLoad job, the results are unexpected. One or more of the affected jobs may not restart.
|Dropping Teradata MultiLoad Work and Error Tables||In the case of a paused Teradata MultiLoad job, do not drop the work tables or the error tables until Teradata MultiLoad completes the import or delete task.
For more information, see Usage Notes.
|Error Table Column Names Not Allowed in Target Tables||Teradata MultiLoad posts the faulty client record information. Teradata MultiLoad also posts information that identifies the record and the type of error to the UV_ and ET_ error tables.
This additional information is provided in eight columns that precede the faulty records from the client system. To maintain the integrity of the Teradata MultiLoad error table information, target tables must not use any of the eight error table column names:
|Session Configurations||There is no general method to determine the optimal number of sessions, because this number is dependent on several factors, including, but not limited to:
Using too few sessions is likely to unnecessarily limit throughput. On the other hand, using too many sessions can increase session management overhead (and also reduce the number of sessions available to any other applications) and may, in some circumstances, degrade throughput.
Regardless of the size of the Teradata Database configuration, for large repetitive production applications, it will usually be appropriate to experiment with several different session configurations to determine the best trade-off between resource utilization and throughput performance.
For larger Teradata Database configurations, it is appropriate to establish an installation default for the maximum number of sessions that is less than one session per AMP. This can be done either with the installation configuration file (see Teradata MultiLoad Command Conventions) or with a standard run-time parameter (see Teradata MultiLoad Command Conventions). An installation default for number of sessions, if specified in the configuration file, can be overridden in individual Teradata MultiLoad scripts, when necessary.
|Unspecified Target Objects||During processing after the BEGIN MLOAD command, Teradata MultiLoad terminates with an error message if it encounters a reference to:
|Views as Import Target Objects||To be a valid target object in a Teradata MultiLoad import task, a view must:
Also, a view must not: