The Teradata Fastload utility loads data into empty tables. It has the ability to be restarted after a database reset or after a client process or platform failure. A Fastload job step should provide the capability to either restart at the point of failure or to completely rerun the step.
It will automatically restart a job after a database failure after the cause of the failure has been fixed and the database has reset. The database configuration must be exactly the same as when the Fastload job was initiated and the Fastload error tables must not have been de-leted. When these conditions are not true the Fastload job must be re-executed from the beginning.
A checkpoint interval can be established as part of the BEGIN LOADING command. This allows a restart to continue reading an input file at the point after the last checkpoint taken before a failure or inter-ruption occurs. The checkpoint interval is set as number of records read for each checkpoint.
When a database reset occurs the Fastload utility will continue to try to re-establish a database connection. When a connection is established the utility will continue the interrupted job automatically. If a check-point has been set it will continue at the point in the input file where the last checkpoint was taken. Specifying a checkpoint interval will de-crease the time needed for a restart but there are tradeoffs. Using checkpoints can increase the execution time of the job. The following factors should be considered when specifying a checkpoint in-terval:
- Each checkpoint temporarily halts the multiple session data transfer feature of Teradata Fastload, thereby decreasing the speed of the Teradata Fastload job.
- For each checkpoint, Teradata Fastload waits for each session to complete sending its current request, which interrupts the data transfer operation.
The record size and the size of the Teradata Database influence how often you should specify checkpoints. On a smaller Teradata Database, specify checkpoints:
- Every 50,000 records if each record is more then 4 KB
- Every 100,000 records if each record is less than 4 KB
- On a larger Teradata Database, specify higher (less frequent) checkpoint values.
The procedure used and the Teradata Fastload response to restarting a paused Teradata Fastload job depends on the phase that the Teradata Fastload job was in when it was paused.
A job that was paused during loading can be can be restarted, either from the beginning or from the most recent checkpoint if the BEGIN LOADING command specified the checkpoint option. A job that was paused during end loading phase will restart from wherever it was interrupted. This is because the Teradata Database uses internal checkpointing during this phase.
A Fastload job that terminates because of a Fastload script error may be restarted after the error is corrected. Commands that have exe-cuted successfully must not be changed in the script. This will cause the restart to fail. If commands that have successfully executed have to be changed the entire Fastload job must be re-executed.
In some cases a Fastload job may need to be re-executed when the error tables or target tables are not available or the database configuration has changed. In the previous example the original Fastload job can be rerun because it drops the error and target tables and recreates the target table before loading the data.