Teradata Parallel Data Pump

Chapter 1: Overview
Teradata TPump Utility
fields with the KEY modifier when the fields are part of the primary index of the table. If the
DML statements in the Teradata TPump script specify more than one target table then it is up
to the script author to make sure that primary indices of all the tables match when using the
serialization feature.
The serialization feature works by hashing each data record based upon its key to determine
which session transmits the record to the database. Thus the extra overhead in the application
is derived from the mathematical operation of hashing and from the extra amount of
buffering necessary to save data rows when a request is already pending on the session chosen
for transmission.
The serialization feature greatly reduces the potential frequency of database deadlock.
Deadlocks can occur when requests for the application happen to affect row(s) that use the
same hash code within the database. Although deadlocks are handled by the database and by
Teradata TPump correctly, the resolution process is time-consuming and adds additional
overhead to the application because it must re-execute requests that roll back due to deadlock.
In addition to using SERIALIZEON in the BEGIN LOAD command, the SERIALIZEON
keyword can also be specified in the DML command. This lets serialization to be turned on for
the fields specified. For more information on the DML-based serialization feature, refer to
“DML” on page 115.
Dual Database Strategy
The serialization feature is intended to support a variety of other potential customer
applications that go under the general heading dual database. These are applications that in
some way take a live feed of inserts, updates, and deletes from another database and apply
them without any preprocessing to Teradata Database.
Both Teradata TPump and MultiLoad are potential parts of the dual database strategy. A dual
database application will generate a DML stream which will be routed to Teradata TPump or
MultiLoad through a paramod/inmod specific to the application. The choice between
Teradata TPump or MultiLoad will depend on such things as the volume of data (with higher
volumes favoring MultiLoad) and the concurrent access requirements (with greater access
requirements favoring Teradata TPump).
Resource Usage and Limitations
A feature unique to Teradata TPump is the ability to constrain run-time resource usage
through the statement rate feature. Teradata TPump provides control over the rate per minute
at which statements are sent to the database and the statement rate correlates directly to
resource usage on both the client and in the database. The statement rate can be controlled in
two ways, either dynamically while the job is running, or it can be scripted into the job with
the RATE keyword on the BEGIN LOAD command. Dynamic control over the statement rate
is provided by updates to a table on the database.
In contrast with Teradata TPump, MultiLoad always uses CPU and memory very efficiently.
During phase one (assuming that the database is not a bottleneck), MultiLoad will probably
bottleneck on the client, consuming significant network or channel resources. During phase
two, MultiLoad uses very significant database disk, CPU, and memory resources. In fact, the
database limits the number of concurrent MultiLoad, FastLoad, and FastExport jobs for the
Teradata Parallel Data Pump Reference 21