Teradata bteq utility by example

BTEQ Commands

The BTEQ commands in Teradata are designed for flexibility. These commands are not used directly on the data inside the tables. However, these 60 different BTEQ

commands are utilized in four areas.

· Session Control Commands

· File Control Commands

· Sequence Control Commands

· Format Control Commands

Session Control Commands

ABORT Abort any and all active running requests and transactions, but do not exit BTEQ.

DEFAULTS Reset all BTEQ Format command options to their defaults. This will utilize the default

configurations.

EXIT Immediately end the current session or sessions and exit BTEQ.

HALT EXECUTION Abort any and all active running requests and transactions and EXIT BTEQ.

LOGOFF End the current session or sessions, but do not exit BTEQ.

LOGON Starts a BTEQ Session. Every user, application, or utility must LOGON to Teradata to

establish a session.

QUIT End the current session or sessions and exit BTEQ.

SECURITY Specifies the security level of messages between a network-attached system and the

Teradata Database.

SESSIONS Specifies the number of sessions to use with the next LOGON command.

SESSION CHARSET Specifies the name of a character set for the current session or sessions.

SESSION SQLFLAG Specifies a disposition of warnings issued in response to violations of ANSI syntax. The

SQL will still run, but a warning message will be provided. The four settings are FULL,

INTERMEDIATE, ENTRY, and NONE.

SESSION TRANSACTION Specifies whether transaction boundaries are determined by Teradata SQL or ANSI

SQL semantics.

SHOW CONTROLS Displays all of the BTEQ control command options currently configured.

SHOW VERSIONS Displays the BTEQ software release versions.

TDP Used to specify the correct Teradata server for logons for a particular session.

Figure 2-11

File Control Commands

These BTEQ commands are used to specify the formatting parameters of incoming and outgoing information. This includes identifying sources and determining I/O

streams.

CMS Execute a VM CMS command inside the BTEQ environment.

ERROROUT Write error messages to a specific output file.

EXPORT Open a file with a specific format to transfer information directly from the Teradata database.

HALT EXECUTION Abort any and all active running requests and transactions and EXIT BTEQ.

FORMAT Enable/inhibit the page-oriented format command options.

IMPORT Open a file with a specific format to import information into Teradata.

INDICDATA One of multiple data mode options for data selected from Teradata. The modes are

INDICDATA, FIELD, or RECORD MODE.

OS Execute an MS-DOS, PC-DOS, or UNIX command from inside BTEQ.

QUIET Limit BTEQ output displays to all error messages and request processing statistics.

REPEAT Submit the next request a certain amount of times

RUN Execute Teradata SQL requests and BTEQ commands directly from a specified run file.

TSO Execute an MVS TSO command from inside the BTEQ environment.

Figure 2-12

Sequence Control Commands

These commands control the sequence in which Teradata commands operate.

ABORT Abort any active transactions and requests.

ERRORLEVEL Assign severity levels to particular error numbers.

EXIT End the current session or sessions and exit BTEQ.

GOTO Skip all intervening commands and resume after branching forward to the specified label.

HANG Pause BTEQ processing for a specific amount of time.

IF…THEN Test a stated condition, and then resume processing based on the test results.

LABEL The GOTO command will always GO directly TO a particular line of code based on a label.

MAXERROR Specifies a maximum allowable error severity level.

QUIT End the current session or sessions and exit BTEQ.

REMARK Place a comment on the standard output stream.

REPEAT Submit the next request a certain amount of times.

Figure 2-13

Format Control Commands

These commands control the formatting for Teradata and present the data in a report mode to the screen or printer.

DEFAULTS Reset all BTEQ Format command options to their defaults. This will utilize the default

configurations.

ECHOREQ Enable the Echo required function in BTEQ returning a copy of each Teradata SQL request and

BTEQ command to the standard output stream.

EXPORT Open a file with a specific format to transfer information directly from the Teradata database.

FOLDLINE Split or fold each line of a report into multiple lines.

FOOTING Specify a footer to appear at the bottom of every report page.

FORMAT Enable/inhibit the page-oriented format command options.

IMPORT Open a file with a specific format to transfer or IMPORT information directly to Teradata.

INDICDATA One of multiple data mode options for data selected from Teradata. The modes are INDICDATA,

FIELD, or RECORD MODE.

NULL Specifies a character or string of characters to represent null values returned from Teradata.

OMIT Omit specific columns from a report.

PAGEBREAK Ejects a page whenever a specified column changes values.

PAGELENGTH Specifies the page length of printed reports based on lines per page.

QUIET Limit BTEQ output displays to all error messages and request processing statistics.

RECORDMODE One of multiple data mode options for data selected from Teradata. (INDICDATA, FIELD, or

RECORD).

RETCANCEL Cancel a request when the specified value of the RETLIMIT command option is exceeded.

RETLIMIT Specifies the maximum number of rows to be displayed or written from a Teradata SQL request.

RETRY Retry requests that fail under specific error conditions.

RTITLE Specify a header appearing at the top of all pages of a report.

SEPARATOR Specifies a character string or specific width of blank characters separating columns of a report.

SHOWCONTROLS Displays all of the BTEQ control command options currently configured.

SIDETITLES Place titles to the left or side of the report instead of on top.

SKIPLINE Inserts blank lines in a report when the value of a column changes specified values.

SUPPRESS Replace each and every consecutively repeated value with completely-blank character strings.

TITLEDASHES Display dash characters before each report line summarized by a WITH clause.

UNDERLINE Display a row of dash characters when the specified column changes values.

WIDTH Specifies the width of screen displays and printed reports, based on characters per line.

Figure 2-14

BTEQ EXPORT Example Using Field (Report) Mode

The following is an example that displays how to utilize the export Field (Report) option. Notice the periods (.) at the beginning some of script lines. A period starting

a line indicates a BTEQ command and needs no semi-colon. Likewise, if there is no period, then the command is an SQL command and requires a semi-colon.r

.LOGON CDW/sql01,whynot; Logon to TERADATA

DATABASE SQL_Class;

.EXPORT REPORT FILE = C:\EMPS.TXT

SELECT * FROM Employee_Table;

This Export statement will be in field (REPORT)

mode. The EMPS.TXT file will be created as a

report.

.IF ERRORCODE > 0 THEN .GOTO Done

SELECT * FROM Department_Table;

BTEQ checks to ensure no errors occurred

and selects more rows – else GOTO Done.

.EXPORT RESET

.LABEL Done

.QUIT

Reverse previous export command and fall

through to Done.

Figure 2-7

After this script has completed, the following report will be generated on disk.

Employee_No Last_name First_name Salary Dept_No

2000000 Jones Squiggy 32800.5 ?

1256349 Harrison Herbert 54500.00 400

1333454 Smith John 48000.00 200

1121334 Strickling Cletus 54500.00 400

1324657 Coffing Billy 41888.88 200

2341218 Reilly William 36000.00 400

1232578 Chambers Mandee 56177.50 100

1000234 Smythe Richard 64300.00 10

2312225 Larkins Loraine 40200.00 300

I remember when my mom and dad purchased my first Lego set. I was so excited about building my first space station that I ripped the box open, and proceeded to

follow the instructions to complete the station. However, when I was done, I was not satisfied with the design and decided to make changes. So I built another space

ship and constructed another launching station. BTEQ export works in the same manner, as the basic EXPORT knowledge is acquired, the more we can build on that

foundation.

With that being said, the following is an example that displays a more robust example of utilizing the Field (Report) option. This example will export data in Field

(Report) Mode format. The output of the exported data will appear like a standard output of a SQL SELECT statement. In addition, aliases and a title have been added

to the script.


.SET WIDTH 90

.SET FORMAT ON

.SET HEADING ‘Employee Profiles’

Set the format

parameters for the final

report

.EXPORT REPORT FILE = C:\EMP_REPORT.TXT This Export statement

will be in field

(REPORT) mode. The

EMP_REPORT.TXT file

will be created as a

report.

Specifies the columns

that are being selected.

Notice that the columns

have an alias.

.EXPORT RESET

.QUIT

Reverse previous export

command effects.

Figure 2-8

After this script has been completed, the following report will be generated on disk.

Employee Profiles

Employee Number Last Name First Name Salary Department Number

2000000 Jones Squiggy 32800.50 ?

1256349 Harrison Herbert 54500.00 400

1333454 Smith John 48000.00 200

1121334 Strickling Cletus 54500.00 400

1324657 Coffing Billy 41888.88 200

2341218 Reilly William 36000.00 400

1232578 Chambers Mandee 56177.50 100

1000234 Smythe Richard 64300.00 10

2312225 Larkins Loraine 40200.00 300

From this example, a number of BTEQ commands were added to the export script. Below is a review of those commands.

· The WIDTH specifies the width of screen displays and printed reports, based on characters per line.

· The FORMAT command allows the ability to enable/inhibit the page-oriented format option.

· The HEADING command specifies a header that will appear at the top every page of a report.

BTEQ IMPORT Example

BTEQ can also read a file from the hard disk and incorporate the data into SQL to modify the contents of one or more tables. In order to do this processing, the name

and record description of the file must be known ahead of time. These will be defined within the script file.

Format of the IMPORT command:

.IMPORT { FILE | DNAME } = <filename> [,SKIP=n]

The script below introduces the IMPORT command with the Record (DATA) option. Notice the periods (.) at the beginning some of script lines. A period starting a

line indicates a BTEQ command. If there is no period, then the command is an SQL command.

The SKIP option is used when you wish to bypass the first records in a file. For example, a mainframe tape may have header records that should not be processed.

Other times, maybe the job started and loaded a few rows into the table with a UPI defined. Loading them again will cause an error. So, you can skip over them using

this option.

The following example will use a Record (DATA) Mode format. The input of the imported data will populate the Employee_Table.

.SESSIONS 4 Specify the number of

SESSIONS to establish with

Teradata


.IMPORT DATA FILE = C:\EMPS.TXT, SKIP = 2 Specify DATA mode, name the

file to read “EMPS.TXT”, but

skip the first 2 records.

.QUIET ON

.REPEAT *

Limit messages out.

Loop in this script until end of

records in file.

The USING Specifies the field in

the input file and names them.

Specify the insert parameters

for the employee_table

Substitutes data from the fields

into the SQL command.

.QUIT Exit the script after all data

read and rows inserted.

Figure 2-9

From the above example, a number of BTEQ commands were added to the import script. Below is a review of those commands.

· .QUIET ON limits BTEQ output to reporting only errors and request processing statistics. Note: Be careful how you spell .QUIET, else forgetting the E

becomes .QUIT and it will.

· .REPEAT * causes BTEQ to read a specified number of records or until EOF. The default is one record. Using REPEAT 10 would perform the loop 10

times.

· The USING defines the input data fields and their associated data types coming from the host.

The following builds upon the IMPORT Record (DATA) example above. The example below will still utilize the Record (DATA) Mode format. However, this script

will add a CREATE TABLE statement. In addition, the imported data will populate the newly created Employee_Profile table.

.SESSIONS 2 Specify the number of

SESSIONS to establish

with Teradata

.LOGON CSW/sql101.whynot Logon to TERADATA

DATABASE SQL_Class; Make the default

database SQL_Class

This statement will create

the Employee_Profile

table.

.IMPORT INDICDATA FILE = C:\IND-EMPS.TXT This import statement

specifies INDICDATA

mode. The input file is

from a LAN file called

IND-EMPS.TXT.

.QUIET ON Quiet on limits the output

to reporting only errors

and processing statistics.

.REPEAT 120 This causes BTEQ to read

the first 120 records from

the file.

The USING Specifies the

parameters of the input

file.

Specify the insert

parameters for the

employee_profile.

Substitute the values to be

inputted into the SQL

command.

.LOGOFF

.QUIT

Figure 2-10

Notice that some of the scripts have a .LOGOFF and .QUIT. The .LOGOFF is optional because when BTEQ quits, the session is terminated. A logoff makes it a

friendly departure and also allows you to logon with a different user name and password.

BTEQ Return Codes

Return codes are two-digit values that BTEQ returns to the user after completing each job or task. The value of the return code indicates the completion status of the

job or task as follows:

Return Code Description

00 Job completed with no errors.

02 User alert to log on to the Teradata DBS.

04 Warning error.

08 User error.

12 Severe internal error.

You can over-ride the standard error codes at the time you terminate BTEQ. This might be handy for debug purposes. The error code or “return code” can be any

number you specify using one of the following:

Override Code Description

.QUIT 15

.EXIT 15

Determining Out Record Lengths

Some hosts, such as IBM mainframes, require the correct LRECL (Logical Record Length) parameter in the JCL, and will abort if the value is incorrect. The following

page will discuss how to figure out the record lengths.

There are three issues involving record lengths and they are:

· Fixed columns

· Variable columns

· NULL indicators

Fixed Length Columns: For fixed length columns you merely count the length of the column. The lengths are:

INTEGER 4 bytes

SMALLINT 2 bytes

BYTEINT 1 byte

CHAR(10) 10 bytes

CHAR(4) 4 bytes

DATE 4 bytes

DECIMAL(7,2) 4 bytes (packed data, total digits / 2 +1 )

DECIMAL(12,2) 8 bytes

Variable columns: Variable length columns should be calculated as the maximum value plus two. This two bytes is for the number of bytes for the binary length of the

field. In reality you can save much space because trailing blanks are not kept. The logical record will assume the maximum and add two bytes as a length field per

column.

VARCHAR(8) 10 Bytes

VARCHAR(10) 12 Bytes

Indicator columns: As explained earlier, the indicators utilize a single bit for each field. If your record has 8 fields (which require 8 bits), then you add one extra byte to

the total length of all the fields. If your record has 9-16 fields, then add two bytes.

BTEQ batch mode utility :

1) Batch mode utility is used for submitting SQL requests to TD DB. exports the data to client system from Teradata DB.

1) It imports and exports the data from multiple tables to multiple files, it is doing ETL operation (ETL),doing Exception Handling. It reads input data and imports it

to TD DB as insert ,Update or Delete.(But fastexport only does Insert operation).

2) It also implements branching and looping. 3) It Doesn't matter that the table is contains constraints, indexes, triggers etc. 4) BTEQ doing Exception handling but

not Error Capturing. 3) BTEQ can run in both Interactive or Batch mode. 4) It Has ability to branch Forward to a Label based on the return code or an activity

count. 5) It is not automatic restart able and checkpoint configurable.

EXPORTING THE DATA: BTEQ .EXPORT

if you want to export the data then go for

.EXPORT DATA "FILE =<FILENAME> ,LIMIT N --- Limit the no of rows while exporting the data.

INDICDATA DD=<DD NAME>

IMPORTING OF DATA :

.IMPORT DATA "FILE=<FILENAME>" ,SKIP N --- Limit the no of rows while importing the data.

INDICDATA DD=<DDNAME>

REPORT

VARTEXT 'D'

DATA MODE (RECORD MODE) : This is set by. EXPORT DATA ,This will bring data back as a flat file ,each parcel contains a complete record. there are no

headers or white space between the data contained in each column. (It is record by record in format mode here the nulls are represented with 0's and spaces. )

INDICDATA MODE: This is host OS means of recognizing missing or unknown data (NULL) fields. It is just DATA MODE but NULLS are indicated with

indicator bytes. TERADATA columns contains a NULL, the bit for the field is turned on by setting it to a '1'.if not null then 0.

REPORT MODE(FIELD MODE): This is set by .EXPORT REPORT. The output of this bteq export would return column headers. Here the field by field info. will

be exported or imported.

DIFF MODE: data interchange in file format :

VARTEXT : Generally denoted with the delimiters such as TABS.

LIMIT : It is used for limiting the no. of rows while exporting the data.

SKIP : It is used for skipping the no. of rows while importing the data.

Exporting the data in DATA MODE :

.logon 127.0.01/DBC,DBC

database vinayaka;

.Export DATA FILE =C:\DATA_LOG\PARTY1_DATA.TXT;

select * from PARTY;

.export reset

.logoff (save the Export_data.txt in C:\BTEQ\FOLDER)

The Run Script

Start ---> RUN--> CMD ---> BTEQ <C:\BTEQ\EXPORT_DATA.TXT>C:\DATA_LOG\EXPORTLOG.TXT;

Exporting the data in REPORT MODE

.LOGON demodat / dbc, dbc;

.EXPORT REPORT FILE =:C\work\Teradata\bomtextline.txt;

select * from bom_text_line where born_id < 1000;

.OUIT

Exporting data in DATA MODE

.LOGON demodat/ dbc,dbc;

.EXPORT DATA FILE =C:\WORK\teradata\bomtextline.txt;

select * from bom_text_line where bom_idn < 1000;

Exporting the a DATA FILES

.LOGON demodat / financial;

.EXPORT DATA File :=c:\customer_data_file.dat;

Select * From FINANCIAL.CUSTOMER;

.EXPORT RESET;

.LOGOFF;

BTEQ SCRIPT TO EXPORT A REPORT FILES.

.logon demodat / financial;

.export report file =c:\customer_report_file.dat;

Select * from FINANCIAL.CUSTOMER;

.export reset;

.logoff;

Exporting the data in REPORT MODE the following business logic

.LOGON demodat/financial;

.EXPORT REPORT file=c:\customer_report_file.dat;

SELECT * FROM FINANCIAL.CUSTOMER;

.Export reset;

.logoff;

Exporting a REPORT FILE SCRIPT with good format capabilities

.logon demodat / twbdemo;

.export REPORT file :=c:\cust_rep_file_format.dat;

Select storeid as storeid , sales as sales, prodid as prodid

FROM SALESTBL WITH SUM(sales) by storeid;

.export reset;

.logoff;

Example 4:

.logon demodat /financial;

.import data file=c:\customer_data_file.dat;

.repeat *;

USING custid(INTEGER) , income(INTEGER),Yearswithbank(SMALLINT),nbrchildern(SMALLINT),gender(char(1)),maritalstatus(char(1))

INSERT INTO CUSTOMER_BTEQ_TEST

( cust_id, income, Yearswithbank, nbrchildern, gender, marital_status)

values (:cust_id, : income,: Yearswithbank,: nbrchildern,: gender,: marital_status)

.logon demodat /financial;

delete from customer_bteq_test;

.logoff;

Example 5: Using REPEAT with Multiple Sessions.

script1 : Simple script to export a data file for only cust_id.

.logon demodat / financial;

.export data file =c:\raisecust;

SELECT * FROM FINANCIAL.CUSTOMER;

.export reset;

.logoff;

.SET session 2

.REPEAT 2

.IMPORT data file = raisecust

.REPEAT 2

using custid (integer)

Update customer_test_bteq

set income =income *1.07

where cust_id = :cust_id;

.logoff;

2nd Script: FOR EXPORTING THE DATA IN DATA MODE

. Logon 127.0.0.1/dbc,dbc; .set width 600; DATABASE VINAYAKA;

.Export REPORT FILE =C:\DATA_LOG\PARTY1_REPORT.TXT

SEL Partyid as LPARTYID,

CAST( PARTYNAME || '-' || PARTYLOC as varchar (30)) AS PADDRESS,

CASE WHEN PARTYINCOME < 30000 THEN 'POOR'

WHEN PARTYINCOME > 30000 AND PARTYINCOME < 50000 THEN 'AVERAGE' ELSE 'GOOD'

END AS PRATING ,

JDATE ( FORMAT 'DD-MM-YYYY') AS PARTY_JDATE,

substr(ORGANIZATION,1,3) AS ORG_SHORT

from party;

.EXPORT RESET

.LOGOFF;

Example of utilizing the Field (Report) option

.LOGON cdw/sql01,whynot;

.set width 90

.set format on

.set heading 'Employee profiles'

.EXport REPORT FILE =C:\EMP_REPORT.TXT

select employee_no AS "Employee_number",

last_name AS "Last_Name",

Salary AS "salary",

Dept_no AS "Dept_No"

from employee_table;

.EXPORT RESET

.QUIT

.LOGON CDW/SQL01,Whynot;

DATABASE SQL_CLASS;

.EXPORT REPORT FILE =C:\EMPS.TXT

SELECT * FROM EMPLOYEE_TABLE;

IF ERRORCODE > 0 THEN .GOTO DONE

Select * from department_table;

.EXPORT RESET

.LABEL DONE

.QUIT

example of utilizing the Field (Report) option


.set width 90

.set format on





Salary AS "salary",



.EXPORT RESET

.QUIT

Bteq Record (DATA) mode format.

.SESSION 4


.IMPORT DATA FILE = C:\EMPS.TXT,SKIP=2

.QUIET ON ---Limit Msg out.

.REPEAT * ---Loop in this script until end of records in file.

USING P_EMP_NO (INTEGER),

P_L_NAME (CHAR(20)),

P_F_NAME (VARCHAR(12)),

P_Salary (Decimal(8,2)),

P_Dept_no (SMALLINT)

Insert into employee_table

(Employee_no,

last_name,

first_name,

salary,

dept_no);

values

(P_EMP_NO,

P_L_NAME

P_F_NAME,

P_Salary,

P_Dept_no);

QUIT;

------------------------------------------------------------------------------------------------------------------------------

BTEQ IMPORT EXAMPLE importing employee_name

.SESSION 4


.IMPORT DATA FILE =C:\EMPS.TXT,SKIP =2

.QUIET ON ---Limit msg out.

.REPEAT * ---loop in script until end of records.


P_L_NAME (CHAR(20),


P_SALARY(DECIMAL(8,2)),

P_DEPT_NO (SMALLINT)

INSERT INTO Employee_table

(Employee_no,

last_name,

first_name,

salary,

dept_no)

values

(:P_EMP_NO,

:P_L_NAME,

:P_F_NAME,

:P_SALARY,

: P_DEPT_NO);

.QUIT

BTEQ RETURN CODES

00 - Job completed Sucessfully.

02 - User alert

04 - Warning error.

08 - User error.

12 - severe internal error.


DATABASE SQL_CLASS;

.EXPORT REPORT FILE =C:\EMPS.TXT

SELECT * FROM EMPLOYEE_TABLE;

IF ERRORCODE > 0 THEN .GOTO DONE

Select * from department_table;

.EXPORT RESET

.LABEL DONE

.QUIT

example of utilizing the Field (Report) option


.set width 90

.set format on





Salary AS "salary",



.EXPORT RESET

.QUIT

Bteq Record (DATA) mode format.

.SESSION 4


.IMPORT DATA FILE = C:\EMPS.TXT,SKIP=2

.QUIET ON ---Limit Msg out.

.REPEAT * ---Loop in this script until end of records in file.


P_L_NAME (CHAR(20)),


P_Salary (Decimal(8,2)),

P_Dept_no (SMALLINT)

Insert into employee_table

(Employee_no,

last_name,

first_name,

salary,

dept_no);

values

(P_EMP_NO,

P_L_NAME

P_F_NAME,

P_Salary,

P_Dept_no);

QUIT;

---------------------------------------------------------------------------------------------------------------------------------------------

BTEQ IMPORT EXAMPLE importing employee_name

.SESSION 4


.IMPORT DATA FILE =C:\EMPS.TXT,SKIP =2

.QUIET ON ---Limit msg out.

.REPEAT * ---loop in script until end of records.


P_L_NAME (CHAR(20),


P_SALARY(DECIMAL(8,2)),

P_DEPT_NO (SMALLINT)

INSERT INTO Employee_table

(Employee_no,

last_name,

first_name,

salary,

dept_no)

values (:P_EMP_NO,

:P_L_NAME,

:P_F_NAME,

:P_SALARY,

: P_DEPT_NO);

.QUIT

BTEQ RETURN CODES

00 - Job completed Sucessfully.

02 - User alert

04 - Warning error.

08 - User error.

12 - severe internal error.

--------------------------------------------------------------------------------------------------------------------------------------------------------------

.logon demodat/financial;

.import data file=c:\customer_data_file.dat;

.repeat*;

A fast load example in its simplest form

Fast load starts with Begin Loading and End loading.

1) It loads data into empty table,

2) Compare to all utilities it is faster and command driven utility

used for loading large amount of data into TD tables.

3) It cannot load duplicates, Error records will be handled separately.

3) It is automatic restart able and check point configurable.

4) It Has the ability to load data into several stages also it operates into multiple sessions.

5) Target table must be empty and should not have secondary indexes,

: Fast Load Has some Limitations :

1) It doesn't load Duplicates, No secondary indexes, no referential Integrity(RI), No triggers, No Duplicate Rows are allowed.

,No AMP may go down while Fast load is processing, No more than one data type conversion is allowed per column

during a Fast Load.

2) It does only insert operations between BEGIN and END LOADING.

3) It Does automatic data conversion b/w (( Numberic to character, date to character, character to date, character to numeric. ))

4) FASTLOAD FIRST PHASE ---> (Acquisition phase/Insert phase). FILE ---> AMP

Fast load user one SQL session to define AMP steps.

The PE sends a block of each AMP which stores block of unsorted data records.

AMPS has each record and redistributes them to AMP responsible for hash value.

Records are written to target table as an unsorted blocks of data.

5) FASTLOAD SECOND PHASE ---> (Application Phase/end loading phase). AMP ---> TABLE

At completion of data loading, each AMP sorts target table, put rows into blocks and writes blocks to disks.

Error TABLES: They are 2 types ET,UV constraints

Errortable1 (ET TABLE 1): data consersion, constraint violation, unavailable AMP ERROR.

Errortable (ET TABLE 2): UNIQUE VIOLATION

1 vinay

2 madhu

3 krishna ------> first 3 records are loaded sucessfully.

T rajesh ---------> data conversion problem (errortable1) .

2 kishore ----------> Unique constraint violation(errortable2) .

1 Vinay ------------> Duplicate records displayed in Log file.

Fastload starts with Begin Loading and End loading.

1) It loads data into empty table,

2) Compare to all utilities it is faster and command driven utility

used for loading large amount of data into TD tables.

3) It cannot load duplicates, Error records will be handled separately.

3) It is automatic restartable and check point configurable.

4) It Has the ability to load data into serveral stages also it operates into multiple

sessions.

5) Target table must be empty and should not have secondary indexes,

: Fastload Has some limitations :

1) It doesn't load Duplicates,No secondary indexes,no referential Integrity(RI),No triggers,No Duplicate Rows are allowed.

,No AMP may go down while Fastload is processing,No more than one data type conversion is allowed per column

during a FastLoad.

2) It does only insert operations between BEGIN and END LOADING.

3) It Does automatic data convsersion b/w Numberic to character,

date to character,character to date,character to numeric.

4) FASTLOAD FIRST PHASE ---> (Aquisition phase/Insert phase).

Fastload user one SQL session to define AMP steps.

The PE sends a block of each AMP which stores block of unsorted data records.

AMPS has each record and redistributes them to AMP responsible for hash value.

Records are written to target table as an unsorted blocks of data.

5) FASTLOAD SECOND PHASE ---> (Application Phase/end loading phase).

AMP ---> TABLE

At completion of data loading,each AMP sorts target table,put rows into blocks and writes

blocks to disks.

Fastload Ulility :

An Introduction to FastLoad

Why it is called “FAST”Load

FastLoad is known for its lightning-like speed in loading vast amounts of data from flat files from a host into empty tables in Teradata. Part of this speed is achieved

because it does not use the Transient Journal. You will see some more of the reasons enumerated below. But, regardless of the reasons that it is fast, know that

FastLoad was developed to load millions of rows into a table.

The way FastLoad works can be illustrated by home construction, of all things! Let’s look at three scenarios from the construction industry to provide an amazing

picture of how the data gets loaded.

Scenario One: Builders prefer to start with an empty lot and construct a house on it, from the foundation right on up to the roof. There is no pre-existing construction,

just a smooth, graded lot. The fewer barriers there are to deal with, the quicker the new construction can progress. Building custom or spec houses this way is the fastest

way to build them. Similarly, FastLoad likes to start with an empty table, like an empty lot, and then populate it with rows of data from another source. Because the

target table is empty, this method is typically the fastest way to load data. FastLoad will never attempt to insert rows into a table that already holds data.

Scenario Two: The second scenario in this analogy is when someone buys the perfect piece of land on which to build a home, but the lot already has a house on it. In

this case, the person may determine that it is quicker and more advantageous just to demolish the old house and start fresh from the ground up — allowing for brand

new construction. FastLoad also likes this approach to loading data. It can just 1) drop the existing table, which deletes the rows, 2) replace its structure, and then 3)

populate it with the latest and greatest data. When dealing with huge volumes of new rows, this process will run much quicker than using MultiLoad to populate the

existing table. Another option is to DELETE all the data rows from a populated target table and reload it. This requires less updating of the Data Dictionary than

dropping and recreating a table. In either case, the result is a perfectly empty target table that FastLoad requires!

Scenario Three: Sometimes, a customer has a good house already but wants to remodel a portion of it or to add an additional room. This kind of work takes more time

than the work described in Scenario One. Such work requires some tearing out of existing construction in order to build the new section. Besides, the builder never

knows what he will encounter beneath the surface of the existing home. So you can easily see that remodeling or additions can take more time than new construction.

In the same way, existing tables with data may need to be updated by adding new rows of data. To load populated tables quickly with large amounts of data while

maintaining the data currently held in those tables, you would choose MultiLoad instead of FastLoad. MultiLoad is designed for this task but, like renovating or adding

onto an existing house, it may take more time.

How FastLoad Works

What makes FastLoad perform so well when it is loading millions or even billions of rows? It is because FastLoad assembles data into 64K blocks (64,000 bytes) to

load it and can use multiple sessions simultaneously, taking further advantage of Teradata’s parallel processing.

This is different from BTEQ and TPump, which load data at the row level. It has been said, “If you have it, flaunt it!” FastLoad does not like to brag, but it takes full

advantage of Teradata’s parallel architecture. In fact, FastLoad will create a Teradata session for each AMP (Access Module Processor — the software processor in

Teradata responsible for reading and writing data to the disks) in order to maximize parallel processing. This advantage is passed along to the FastLoad user in terms of

awesome performance. Teradata is the only data warehouse product in the world that loads data, processes data and backs up data in parallel.

FastLoad Has Some Limits

There are more reasons why FastLoad is so fast. Many of these become restrictions and therefore, cannot slow it down. For instance, can you imagine a sprinter

wearing cowboy boots in a race? Of course, not! Because of its speed, FastLoad, too, must travel light! This means that it will have limitations that may or may not

apply to other load utilities. Remembering this short list will save you much frustration from failed loads and angry colleagues. It may even foster your reputation as a

smooth operator!

Rule #1: No Secondary Indexes are allowed on the Target Table. High performance will only allow FastLoad to utilize Primary Indexes when loading. The reason

for this is that Primary (UPI and NUPI) indexes are used in Teradata to distribute the rows evenly across the AMPs and build only data rows. A secondary index is

stored in a subtable block and many times on a different AMP from the data row. This would slow FastLoad down and they would have to call it: get ready now,

HalfFastLoad. Therefore, FastLoad does not support them. If Secondary Indexes exist already, just drop them. You may easily recreate them after completing the load.

Rule #2: No Referential Integrity is allowed. FastLoad cannot load data into tables that are defined with Referential Integrity (RI). This would require too much

system checking to prevent referential constraints to a different table. FastLoad only does one table. In short, RI constraints will need to be dropped from the target

table prior to the use of FastLoad.

Rule #3: No Triggers are allowed at load time. FastLoad is much too focused on speed to pay attention to the needs of other tables, which is what Triggers are all

about. Additionally, these require more than one AMP and more than one table. FastLoad does one table only. Simply ALTER the Triggers to the DISABLED status

prior to using FastLoad.

Rule #4: Duplicate Rows (in Multi-Set Tables) are not supported. Multi-set tables are tables that allow duplicate rows — that is when the values in every column

are identical. When FastLoad finds duplicate rows, they are discarded. While FastLoad can load data into a multi-set table, FastLoad will not load duplicate rows into a

multi-set table because FastLoad discards duplicate rows!

Rule #5: No AMPs may go down (i.e., go offline) while FastLoad is processing. The down AMP must be repaired before the load process can be restarted. Other

than this, FastLoad can recover from system glitches and perform restarts. We will discuss Restarts later in this chapter.

Rule #6: No more than one data type conversion is allowed per column during a FastLoad. Why just one? Data type conversion is highly resource intensive job

on the system, which requires a “search and replace” effort. And that takes more time. Enough said!

Three Key Requirements for FastLoad to Run

FastLoad can be run from either MVS/ Channel (mainframe) or Network (LAN) host. In either case, FastLoad requires three key components. They are a log table, an

empty target table and two error tables. The user must name these at the beginning of each script.

Log Table: FastLoad needs a place to record information on its progress during a load. It uses the table called Fastlog in the SYSADMIN database. This table contains

one row for every FastLoad running on the system. In order for your FastLoad to use this table, you need INSERT, UPDATE and DELETE privileges on that table.

Empty Target Table: We have already mentioned the absolute need for the target table to be empty. FastLoad does not care how this is accomplished. After an initial

load of an empty target table, you are now looking at a populated table that will likely need to be maintained.

If you require the phenomenal speed of FastLoad, it is usually preferable, both for the sake of speed and for less interaction with the Data Dictionary, just to delete all

the rows from that table and then reload it with fresh data. The syntax DELETE <databasename>.<tablename> should be used for this. But sometimes, as in some of

our FastLoad sample scripts (see Figure 4-2), you want to drop that table and recreate it versus using the DELETE option. To do this, FastLoad has the ability to run the

DDL statements DROP TABLE and CREATE TABLE. The problem with putting DDL in the script is that is no longer restartable and you are required to rerun the

FastLoad from the beginning. Otherwise, we recommend that you have a script for an initial run and a different script for a restart.

Two Error Tables: Each FastLoad requires two error tables. These are error tables that will only be populated should errors occur during the load process. These are

required by the FastLoad utility, which will automatically create them for you; all you must do is to name them. The first error table is for any translation errors or

constraint violations. For example, a row with a column containing a wrong data type would be reported to the first error table. The second error table is for errors

caused by duplicate values for Unique Primary Indexes (UPI). FastLoad will load just one occurrence for every UPI. The other occurrences will be stored in this table.

However, if the entire row is a duplicate, FastLoad counts it but does not store the row. These tables may be analyzed later for troubleshooting should errors occur

during the load. For specifics on how you can troubleshoot, see the section below titled, “What Happens When FastLoad Finishes.”

Maximum of 15 Loads

The Teradata RDBMS will only run a maximum number of fifteen FastLoads, MultiLoads, or FastExports at the same time. This maximum is determined by a value

stored in the DBS Control record. It can be any value from 0 to 15. When Teradata is first installed, this value is set to 5 concurrent jobs.

Since these utilities all use the large blocking of rows, it hits a saturation point where Teradata will protect the amount system resources available by queuing up the

extra load. For example, if the maximum number of jobs are currently running on the system and you attempt to run one more, that job will not be started. You should

view this limit as a safety control. Here is a tip for remembering how the load limit applies: If the name of the load utility contains either the word “Fast” or the word

“Load”, then there can be only a total of fifteen of them running at any one time.

Converting Data Types with FastLoad

Converting data is easy. Just define the input data types in the input file. Then, FastLoad will compare that to the column definitions in the Data Dictionary and convert the data for you! But the cardinal rule is that only one data type conversion is allowed per column. In the example below, notice how the columns in the input file are converted from one data type to another simply by redefining the data type in the CREATE TABLE statement.

FastLoad allows six kinds of data conversions. Here is a chart that displays them:

IN FASTLOAD YOU MAY CONVERT

CHARACTER DATA TO NUMERIC DATA

FIXED LENGTH DATA TO VARIABLE LENGTH DATA

CHARACTER DATA TO DATE

INTEGERS TO DECIMALS

DECIMALS TO INTEGERS

DATE TO CHARACTER DATA

NUMERIC DATA TO CHARACTER DATA

Figure 4-4

When we said that converting data is easy, we meant that it is easy for the user. It is actually quite resource intensive, thus increasing the amount of time needed for the load. Therefore, if speed is important, keep the number of columns being converted to a minimum!

FastLoad Commands

Here is a table of some key FastLoad commands and their definitions. They are used to provide flexibility in control of the load process. Consider this your personal redi-reference guide! You will notice that there are only a few SQL commands that may be used with this utility (Create Table, Drop Table, Delete and Insert). This keeps FastLoad from becoming encumbered with additional functions that would slow it down.

AXSMOD Short for Access Module, this command specifies input protocol like OLE-DB or reading a tape from REEL Librarian. This parameter is for network-attached systems only. When used, it must precede the DEFINE command in the script.

BEGIN LOADING This identifies and locks the FastLoad target table for the duration of the load. It also identifies the two error tables to be used for the load. CHECKPONT and INDICATORS are subordinate commands in the BEGIN LOADING clause of the script. CHECKPOINT, which will be discussed below in detail, is not the default for FastLoad. It must be specified in the script. INDICATORS is a keyword related to how FastLoad handles nulls in the input file. It identifies columns with nulls and uses a bitmap at the beginning of each row to show which fields contain a null instead of data. When the INDICATORS option is on, FastLoad looks at each bit to identify the null column. The INDICATORS option does not work with VARTEXT.

CREATE TABLE This defines the target table and follows normal syntax. If used, this should only be in the initial script. If the table is being loaded, it cannot be created a second time.

DEFINE This names the Input file and describes the columns in that file and the data types for those columns.

DELETE Deletes all the rows of a table. This will only work in the initial run of the script. Upon restart, it will fail because the table is locked.

DROP TABLE Drops a table and its data. It is used in FastLoad to drop previous Target and error tables. At the same time, this is not a good thing to do within a FastLoad script since it cancels the ability to restart.

END LOADING Success! This command indicates the point at which that all the data has been transmitted. It tells FastLoad to proceed to Phase II. As mentioned earlier, it can be used as a way to partition data loads to the same table. This is true because the table remains empty until after Phase II.

ERRLIMIT Specifies the maximum number of rejected ROWS allowed in error table 1 (Phase I). This handy command can be a lifesaver when you are not sure how corrupt the data in the Input file is. The more corrupt it is, the greater the clean up effort required after the load finishes. ERRLIMIT provides you with a safety valve. You may specify a particular number of error rows beyond which FastLoad will immediately precede to the abort. This provides the option to restart the FastLoad or to scrub the input data more before loading it. Remember, all the rows in the error table are not in the data table. That becomes your responsibility.

HELP Designed for online use, the Help command provides a list of all possible FastLoad commands along with brief, but pertinent tips for using them.

HELP TABLE Builds the table columns list for use in the FastLoad DEFINE statement when the data matches the Create Table statement exactly. In real life this does not happen very often.

INSERT This is FastLoad’s favorite command! It inserts rows into the target table.

LOGON/LOGOFF or, QUIT

No, this is not the WAX ON / WAX OFF from the movie, The Karate Kid! LOGON simply begins a session. LOGOFF ends a session. QUIT is the same as LOGOFF.

NOTIFY Just like it sounds, the NOTIFY command used to inform the job that follows that some event has occurred. It calls a user exit or predetermined activity when such events occur. NOTIFY is often used

for detailed reporting on the FastLoad job’s success.

RECORD Specifies the beginning record number (or with THRU, the ending record number) of the Input data source, to be read by FastLoad. Syntactically, This command is placed before the INSERT keyword. Why would it be used? Well, it enables FastLoad to bypass input records that are not needed such as tape headers, manual restart, etc. When doing a partition data load, RECORD is used to over-ride the checkpoint. What does this mean???

SET RECORD Used only in the LAN environment, this command states in what format the data from the Input file is coming: FastLoad, Unformatted, Binary, Text, or Variable Text. The default is the Teradata RDBMS standard, FastLoad.

SESSIONS This command specifies the number of FastLoad sessions to establish with Teradata. It is written in the script just before the logon. The default is 1 session per available AMP. The purpose of multiple sessions is to enhance throughput when loading large volumes of data. Too few sessions will stifle throughput. Too many will preclude availability of system resources to other users. You will need to find the proper balance for your configuration.

SLEEP Working in conjunction with TENACITY, the SLEEP command specifies the amount minutes to wait before retrying to logon and establish all sessions. This situation can occur if all of the loader slots are used or if the number of requested sessions are not available. The default is 6 minutes. For example, suppose that Teradata sessions are already maxed-out when your job is set to run. If TENACITY were set at 4 and SLEEP at 10, then FastLoad would attempt to logon every 10 minutes for up to 4 hours. If there were no success by that time, all efforts to logon would cease.

TENACITY Sometimes there are too many sessions already established with Teradata for a FastLoad to obtain the number of sessions it requested to perform its task or all of the loader slots are currently used. TENACITY specifies the amount of time, in hours, to retry to obtain a loader slot or to establish all requested sessions to logon. The default for FastLoad is “no tenacity”, meaning that it will not retry at all. If several FastLoad jobs are executed at the same time, we recommend setting the TENACITY to 4, meaning that the system will continue trying to logon for the number of sessions requested for up to four hours.

Figure 4-1

FastLoad Has Two Phases

Teradata is famous for its end-to-end use of parallel processing. Both the data and the tasks are divided up among the AMPs. Then each AMP tackles its own portion of the task with regard to its portion of the data. This same “divide and conquer” mentality also expedites the load process. FastLoad divides its job into two phases, both designed for speed. They have no fancy names but are typically known simply as Phase 1 and Phase 2. Sometimes they are referred to as Acquisition Phase and Application Phase.

PHASE 1: Acquisition

The primary function of Phase 1 is to transfer data from the host computer to the Access Module Processors (AMPs) as quickly as possible. For the sake of speed, the Parsing Engine of Teradata does not does not take the time to hash each row of data based on the Primary Index. That will be done later. Instead, it does the following:

When the Parsing Engine (PE) receives the INSERT command, it uses one session to parse the SQL just once. The PE is the Teradata software processor responsible for parsing syntax and generating a plan to execute the request. It then opens a Teradata session from the FastLoad client directly to the AMPs. By default, one session is created for each AMP. Therefore, on large systems, it is normally a good idea to limit the number of sessions using the SESSIONS command. This capability is shown below.

Simultaneously, all but one of the client sessions begins loading raw data in 64K blocks for transfer to an AMP. The first priority of Phase 1 is to get the data onto the AMPs as fast as possible. To accomplish this, the rows are packed, unhashed, into large blocks and sent to the AMPs without any concern for which AMP gets the block. The result is that data rows arrive on different AMPs than those they would live, had they been hashed.

So how do the rows get to the correct AMPs where they will permanently reside? Following the receipt of every data block, each AMP hashes its rows based on the Primary Index, and redistributes them to the proper AMP. At this point, the rows are written to a worktable on the AMP but remain unsorted until Phase 1 is complete.

Phase 1 can be compared loosely to the preferred method of transfer used in the parcel shipping industry today. How do the key players in this industry handle a parcel? When the shipping company receives a parcel, that parcel is not immediately sent to its final destination. Instead, for the sake of speed, it is often sent to a shipping hub in a seemingly unrelated city. Then, from that hub it is sent to the destination city. FastLoad’s Phase 1 uses the AMPs in much the same way that the shipper uses its hubs. First, all the data blocks in the load get rushed randomly to any AMP. This just gets them to a “hub” somewhere in Teradata country. Second, each AMP forwards them to their true destination. This is like the shipping parcel being sent from a hub city to its destination city!

PHASE 2: Application

Following the scenario described above, the shipping vendor must do more than get a parcel to the destination city. Once the packages arrive at the destination city, they must then be sorted by street and zip code, placed onto local trucks and be driven to their final, local destinations.

Similarly, FastLoad’s Phase 2 is mission critical for getting every row of data to its final address (i.e., where it will be stored on disk). In this phase, each AMP sorts the rows in its worktable. Then it writes the rows into the table space on disks where they will permanently reside. Rows of a table are stored on the disks in data blocks. The AMP uses the block size as defined when the target table was created. If the table is Fallback protected, then the Fallback will be loaded after the Primary table has finished loading. This enables the Primary table to become accessible as soon as possible. FastLoad is so ingenious, no wonder it is the darling of the Teradata load utilities!

Sample FastLoad Script

Let’s look at an actual FastLoad script that you might see in the real world. In the script below, every comment line is placed inside the normal Teradata comment syntax, [/*. . . . */]. FastLoad and SQL commands are written in upper case in order to make them stand out. In reality, Teradata utilities, like Teradata itself, are by default not case sensitive. You will also note that when column names are listed vertically we recommend placing the comma separator in front of the following column. Coding this way makes reading or debugging the script easier for everyone. The purpose of this script is to update the Employee_Profile table in the SQL01 database. The input file used for the load is named EMPS.TXT. Below the sample script each step will be described in detail.

Normally it is not a good idea to put the DROP and CREATE statements in a FastLoad script. The reason is that when any of the tables that FastLoad is using are dropped, the script cannot be restarted. It can only be rerun from the beginning. Since FastLoad has restart logic built into it, a restart is normally the better solution if the initial load attempt should fail. However, for purposes of this example, it shows the table structure and the description of the data being read.

/* !/bin/ksh* *//* ++++++++++++++++++++++++++++*/

Runs from a shell script.Always good to identify

/* FASTLOAD SCRIPT TO LOAD THE *//* Employee_Profile TABLE *//* Version 1.1 *//* Created by Coffing Data Warehousing *//* ++++++++++++++++++++++++++++*/

/* Setup the FastLoad Parameters */

the script and author in comments.Since this script does not drop the target or error tables, it is restartable. This is a good thing for production jobs.

SESSIONS 100; /*or, the number of sessions supportable*/ Specify the number of sessions to logon.

TENACITY 4; /* the default is no tenacity, means no retry */SLEEP 10; /* the default is 6, means retry in 6 minutes */

LOGON CW/SQL01,SQL01;

Tenacity is set to 4 hr;Wait 10 Min between retries.

SHOW VERSIONS; /* Shows the Utility’s release number */ Display the version of FastLoad.

/* Set the Record type to a comma delimited for FastLoad */ RECORD 2; Starts with the second record.

SET RECORD VARTEXT ‘,’; Specifies if record layout is vartext with a comma delimiter.

Notice that all fields are defined as VARCHAR. When using VARTEXT, the fields do not contain the length field like in these formats: text, FastLoad, or unformatted.

FILE= EMPS.TXT; Defines the flat file name.

/* Optional to show the layout of the input */ SHOW Specifies table to load and lock.

/* Begin the Load and Insert Process into the *//* Employee_Profile Table */

BEGIN LOADING SQL01.Employee_ProfileERRORFILES SQL01.Emp_Err1, SQL01.Emp_Err2

CHECKPOINT 100000;

Names the error tables. Sets the number of rows at which to pause & record progress in the restart log before loading further.

Defines the insert statement to use for loading the rows.

END LOADING; Continues loading process with Phase 2.

LOGOFF; Logs off of Teradata.

Figure 4-3

Step One: Before logging onto Teradata, it is important to specify how many sessions you need. The syntax is [SESSIONS {n}].

Step Two: Next, you LOGON to the Teradata system. You will quickly see that the utility commands in FastLoad are similar to those in BTEQ. FastLoad commands were designed from the underlying commands in BTEQ. However, unlike BTEQ, most of the FastLoad commands do not allow a dot [“.”] in front of them and therefore need a semi-colon. At this point we chose to have Teradata tell us which version of FastLoad is being used for the load. Why would we recommend this? We do because as FastLoad’s capabilities get enhanced with newer versions, the syntax of the scripts may have to be revisited.

Step Three: If the input file is not a FastLoad format, before you describe the INPUT FILE structure in the DEFINE statement, you must first set the RECORD layout type for the file being passed by FastLoad. We have used VARTEXT in our example with a comma delimiter. The other options are FastLoad, TEXT, UNFORMATTED OR VARTEXT. You need to know this about your input file ahead of time.

Step Four: Next, comes the DEFINE statement. FastLoad must know the structure and the name of the flat file to be used as the input FILE, or source file for the load.

Step Five: FastLoad makes no assumptions from the DROP TABLE statements with regard to what you want loaded. In the BEGIN LOADING statement, the script must name the target table and the two error tables for the load. Did you notice that there is no CREATE TABLE statement for the error tables in this script? FastLoad will automatically create them for you once you name them in the script. In this instance, they are named “Emp_Err1” and “Emp_Err2”. Phase 1 uses “Emp_Err1” because it comes first and Phase 2 uses “Emp_Err2”. The names are arbitrary, of course. You may call them whatever you like. At the same time, they must be unique within a database, so using a combination of your userid and target table name helps insure this uniqueness between multiple FastLoad jobs occurring in the same database.

In the BEGIN LOADING statement we have also included the optional CHECKPOINT parameter. We included [CHECKPOINT 100000]. Although not required, this optional parameter performs a vital task with regard to the load. In the old days, children were always told to focus on the three “R’s’ in grade school (“reading, ‘riting, and ‘rithmatic”). There are two very different, yet equally important, R’s to consider whenever you run FastLoad. They are RERUN and RESTART. RERUN means that the job is capable of running all the processing again from the beginning of the load. RESTART means that the job is capable of running the processing again from the point where it left off when the job was interrupted, causing it to fail. When CHECKPOINT is requested, it allows FastLoad to resume loading from the first row following the last successful CHECKPOINT. We will learn more about CHECKPOINT in the section on Restarting FastLoad.

Step Six: FastLoad focuses on its task of loading data blocks to AMPs like little Yorkshire terrier’s do when playing with a ball! It will not stop unless you tell it to stop. Therefore, it will not proceed to Phase 2 without the END LOADING command.

In reality, this provides a very valuable capability for FastLoad. Since the table must be empty at the start of the job, it prevents loading rows as they arrive from different time zones. However, to accomplish this processing, simply omit the END LOADING on the load job. Then, you can run the same FastLoad multiple times and continue loading the worktables until the last file is received. Then run the last FastLoad job with an END LOADING and you have partitioned your load jobs into smaller segments instead of one huge job. This makes FastLoad even faster!

Of course to make this work, FastLoad must be restartable. Therefore, you cannot use the DROP or CREATE commands within the script. Additionally, every script is exactly the same with the exception of the last one, which contains the END LOADING causing FastLoad to proceed to Phase 2. That’s a pretty clever way to do a partitioned type of data load.

Step Seven: All that goes up must come down. And all the sessions must LOGOFF. This will be the last utility command in your script. At this point the table lock is released and if there are no rows in the error tables, they are dropped automatically. However, if a single row is in one of them, you are responsible to check it, take the appropriate action and drop the table manually.

Technology

Teradata bteq utility by example