Specifying the Checkpoint Interval Use one of the following methods to specify the checkpoint interval.

On the tbuild command line using the -z option tbuild -f <script file name> -z <checkpoint interval> Table 14: Checkpoint Types and Functions Checkpoint Type Function Basic (default) If the tbuild command does not specify a checkpoint interval, th e job will automatically take just two checkpoints during each job step that has consumer and producer operators: a Start-of-Data checkpoint an End-of-Data checkpoint These two checkpoints allow Teradata PT jobs to restart automatically, without requiring user intervention, if the interruption was caused by a Teradata server restart or deadlock situation. The default checkpoints can also be used for a manual restart. In either case, the job will restart after the las t checkpoint written to the files. If the End-of-Data checkpoint was taken, the work accomplished between these two checkpoints will not have to be repeated by the restarted job. If the job failed before the End-of-Data checkpoint was taken whatever work was accomplished after the Start-of-Data checkpoint was taken will have to be repeated by the restarted job. This default checkpoint protection against redoing work is quite minimal, so Teradata recommends the use of interval checkpointing. Interval Checkpointing When you specify a checkpoint interval for a Teradata PT job using the tbuild -z command, the job will take a checkpoint for each specified interval (in seconds), for each job step with producer and consumer operators. If a job with interval checkpointing fails to run to completion and is later restarted, the only work that will have to be performed over again is the work done after the last checkpoint was taken. This option offers increased fault tolerance for long running jobs containing a substantial amount of data to be loaded/exported. Direct Command A Teradata PT job can also be directed to take a checkpoint at an y time through the twbcmd command, either explicitly with the JOB CHECKPOINT command option, or implicitly with the JOB PAUSE command option, which suspends job execution after the checkpoint is taken. For details, see the section on Teradata PT utilities in Teradata Parallel Transporter Reference. Operator Initiated The DataConnector operator automatically initiates a checkpoint after processing all the input files found during an interval-driven scan of a directory. Chapter 21: Launching a Job Setting Checkpoint Options 266 Teradata Parallel Transporter User Guide The -z option sets the checkpoint interval to the number of seconds specified. E xperiment with setting the checkpoint interval when doing trial runs of a job to determine the optimum interval. You can also use this method to override a checkpoint interval specified using the SET CHECKPOINT INTERVAL option in the DEFINE JOB statement for the job script, during a particular execution of the job, including restarts. In the job script using the SET CHECKPOINT INTERVAL statement, as shown in the following examples:

SET CHECKPOINT INTERVAL 160 SEC or SET CHECKPOINT INTERVAL 12 MINUTES The checkpoint interval can be specified in a job script between the last DEFINE statement and the APPLY statement(s). This method is appropriate for established jobs for which the desired checkpoint interval has been determined and will seldom or never need to be changed from one run to another of the job script. For information, see the sect ion on DEFINE JOB in Teradata Parallel Transporter Reference. The checkpoint interval must be specified either in SECONDS (or abbreviation SEC ) or MINUTES (or abbreviation MIN). Note: If the checkpoint interval is specified both in the job script and with th e tbuild -z command option, the -z option takes precedence. Note: If the checkpoint interval is set to zero, calls for checkpoint function t o any access modules (attached via the DataConnector Operator) will be bypassed. Should an ac cess modules checkpoint operations be particularly resource intensive, this feature a llows for those checkpoint operations to be bypassed in cases where the user feels that checkpoi nt recovery is not critical. Effects of Interval Checkpointing on Job Performance Checkpoints increase Teradata PT job overhead. In terms of resources, each execu ting operator must do the additional work of writing its internal operating state to the checkpoint file, so that it could be restarted from the information in the checkpoint file. In terms of running time, each executing operator must first finish all in-progress work, ta ke its checkpoint, and then wait (when necessary) until all the other operators have fi nished taking their checkpoints. Frequent checkpoints can guarantee that only a limited amount of work would have to be repeated if the job were interrupted and then later restarted, because it shorte ns the time between an error event and the checkpoint. However, specifying a very short chec kpoint interval can significantly increase job running time. Choosing a checkpoint inte rval is a trade off between the cost in increased job run time and the potential reduction in re peated work if the job must be restarted. Here is an example of a Teradata PT job that loads 20,000,000 rows with 4 instan ces each of the producer and consumer operators: Specifying a checkpoint interval of 10 seconds increased the job's running time by 7.3% and its host CPU time by 3.3%. Chapter 21: Launching a Job Launching a Teradata PT Job Teradata Parallel Transporter User Guide 267 Specifying a checkpoint interval of 5 seconds increased the job's running time b

y 20% and its host CPU time by 6.6%. Even though interval checkpointing may have a substantial performance cost, its usefulness during a possible restart make interval checkpointing a Teradata best practice recommendation. How Checkpoints Affect Job Restarts Jobs sometimes fail to achieve a successful completion. Checkpoints enable faile d jobs to be restarted from the last checkpoint before the failure. Before you restart a job try to understand what caused the failure. You may need to take remedial actions before restarting the job to prevent the failure from occurring again. For further information, see Restarting A Job on page 318.) When you are ready to restart the job, re-issue the same tbuild command used to submit the job the first time. The job will restart at the job step that failed, at the poi nt in that step where the last checkpoint was taken prior to the failure. Launching a Teradata PT Job The following tbuild command executes the job script in file /prod/hdqts.load an d uses the local job variables file named attributeFile : tbuild -f /prod/hdqts.load -v attributeFile Command-Line Handling of String Delimiters in Script Parsing A few simple syntax rules govern the tbuild command, and the other Teradata PT c ommands, at the command prompt on the various supported platforms. These examples suggest that single quotes should be avoided as string delimiters for command-line arguments on all platforms. On All Platforms Double-quote characters ( " ) are interpreted as string delimiters, and are stri pped from the character strings they enclose. A double-quote character as a data character in a string must be escaped with th e backslash character ( \ ). For example: tlogview -j DTAC_FLD1@offshore36-746 -w "TASKNAME=\"SELECT_20001\"" On Windows Systems On UNIX systems, single quotes (') are stripped away so that quotes are not part of the string. But on Windows systems, the quote becomes part of the string. This means that if you run something like this at the Windows command prompt: C:\>tlogview -l 'C:\Program Files\Teradata\client\<version>\Teradata Parallel Transporter\logs\testjob.out' Chapter 21: Launching a Job Launching a Teradata PT Job 268 Teradata Parallel Transporter User Guide the filename is read as 'C:\Program.......testjob.out', including the quotes, wh ich is not the right file name. On UNIX Systems Single-quote characters are also recognized as string delimiters and are strippe d from the character strings they enclose.

A single-quote character can be a data character only when it occurs in a string delimited by double-quote characters. For example, in the command: tbuild -f test_job.twb -u "verb=\"Couldn't\"" the argument of the -u option passed to the tbuild program is the string verb= Co uldn t . On z/OS Batch Systems Command line parameters are entered with the PARM field of the EXEC JCL statemen t for z/OS batch jobs. Single-quote characters are recognized as the PARM field delimiters and are stri pped from the character strings they enclose.