There are few limitations which we have on Fastload:

These limitations are necessary for Fastload to load data with the lightning fast speed into tables.
NO SECONDARY INDEXES ARE ALLOWED ON TARGET TABLE Fastload can load
tables only with primary indexes defined on it. If we have a secondary index on the table then
Fastload will not load that table. We get a error message if we load such type of table
RDBMS error3621:cannot load table employee_table unless secondary index and join are remove
If secondary index exist already, we need to drop them.
After loading the table through Fastload we can easily recreate them on the table.
CREATE INDEX (Column-name/s) ON dbname.tablename > creates Non Unique Secondary
Index
or
CREATE UNIQUE INDEX (Column-name/s) ON dbname.tablename > creates Unique
Secondary Index
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
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.
DUPLICATE ROWS ARE NOT SUPPORTED Multiset tables are a table 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

Restrictions and Limitations
The following sections describe restrictions and limitations relevant for programming with the Teradata
FastLoad utility.
Session Limits
The value specified with the SESSIONS command is not the only factor that limits the number of
sessions that Teradata FastLoad establishes with the Teradata Database. The other limiting factors are:
The Teradata Database limit of one session per AMP.
The platform limit on the maximum number of sessions per application.
This value is defined in the Communications Processor (COP) Interface software file, CLISPB.DAT,
under the MaxSess variable.
The TDP SET MAXSESSIONS command can be used to specify a platform limit. The default limit is
equal to the server MAXSESS.
The limit of the network protocol software on network-attached systems.
When invoking Teradata FastLoad, the actual session limit is determined by whichever limiting factor is
encountered first.
Space Requirements and Limitations
Always estimate the final size of the Teradata FastLoad table, and make sure that the destination database
on the Teradata Database has enough space to accommodate the Teradata FastLoad job. If the database
that owns the Teradata FastLoad table or the error tables runs out of space, the Teradata Database returns
an error message and Teradata FastLoad pauses your Teradata FastLoad job. When this happens, allocate
more space to the database before restarting the job.
Join Index Restrictions
Teradata FastLoad does not maintain join indexes. Teradata FastLoad cannot be used to load data to
tables with an associated join index on a Teradata Database. In this case, first drop the join index, then
recreate it after running the Teradata FastLoad job.
Note: Teradata FastLoad does not support hash and join indexes.
Foreign Key References Limitation
Teradata FastLoad does not support foreign key references in target tables. Attempting a Teradata
FastLoad task or any action against a target table defined with a foreign key constraint produces an error
condition.
Secondary Indexes Limitation
Teradata FastLoad does not support target tables defined with secondary indexes. Attempting a Teradata
FastLoad task against a target table defined with secondary indexes produces an error condition.
To load such a table, first drop the secondary indexes. Then load the table and recreate the secondary
indexes.
Or, alternatively, if only nonunique secondary indexes (NUSI) are involved, consider using MultiLoad.
Note: Teradata FastLoad does not support secondary indexes of any kind.
Referential Integrity Limitation
Attempting a Teradata FastLoad task or any action against tables with [referential integrity|defined
triggers] produces an error condition.
Defined Triggers Limitation
Attempting a Teradata FastLoad task or any action against tables with [referential integrity|defined
triggers] produces an error condition.





















FAST LOAD
Fastload, the name itself telling that loads data in a fast way.That means it loads huge amount of data
from flat file into EMPTY tables.

Manily FastLoad was developed to load millions of rows into empty Teradata tables so it is fast.
FastLoad will create a Teradata session for each AMP in order to maximize parallel processing.This gives
awesome performance in loading data.

There are more reasons why FastLoad is so fast. Below are limitations of Fast load.
1) No Secondary I ndexes are allowed on the Target Table: Usually UPI and NUPI are used in Teradata
to distribute the rows evenly across the AMPs.Secondary indexes are stored in a subtable block and many
times on a different AMP from the data row.

2)No Referential I ntegrity is allowed: The Referential Integrity defined on a table would take more
system checking to prevent referential constraints.

3)No Triggers are allowed at load time: Fast load focused on data load with high speed. So triggers not
allowed.

4)Duplicate Rows (in Multi-Set Tables) are not supported: Multiset tables are allowed duplicate data.
Fastload can load the data into multiset tables but duplicate rows are discarded.

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

6)No more than one data type conversion is allowed per column: Data type conversion cause high
resource utilization on the system

Fastload requires mainly three components

Log table
Log table stores the processing record information during load.This table contains one row for every
FastLoad running on the system

Empty Target table
As mentioned earlier target tables should be empty.

Error tables(two)
Each FastLoad requires two error tables. These are automatically created during run. These will populated
only errors occurred during the load.

The first error table is for any translation errors or constraint violations
For example, if a column is defined as integer but the data from source the data is coming in CHAR
format.i.e wrong data.

The second error table is for errors caused by duplicate values for Unique Primary Indexes.


FastLoad Has Two Phases:

FastLoad divides its job into two phases, both designed for speed.

Phase 1 or Acquisition Phase
The primary purpose of phase 1 is to get data from host computer into Teradata System.
The data moves in 64 K blocks and is stored in worktables on the AMPs.
The data is not stored in the correct AMP.

Phase 2 or Application Phase.
Once the data is moved from the server, each AMP will hash its worktable rows.
Each each row transfers to the worktables where they permanently resides
Rows of a table are stored on the disks in data blocks

Simple fastload Script:
1. Logging onto Teradata
2. Defining the Teradata table that you want to load (target table)
3. Defining the INPUT data file
4. Telling the system to start loading
5. Telling the system to to insert data into final target.
6. End session.


LOGON TDDB/USERNAME,PWD;

CREATE TABLE EMPDB.EMP_TABLE
( EMP_NUM INTEGER
,DEPT_NUM SMALLINT
,FIRST_NAME CHAR(20)
,LAST_NAME VARCHAR(20)
,SALARY DECIMAL(8,2)
UNIQUE PRIMARY INDEX(EMP_NUM);

DEFINE EMP_NUM (INTEGER)
,DEPT_NUM (SMALLINT)
,FIRST_NAME (CHAR(20))
,LAST_NAME (VARCHAR(20))
,SALARY (DECIMAL(8,2))
FILE=C:\TEMP\EMP_FILE.txt;

BEGIN LOADING EMPDB.EMP_TABLE
ERRORILES EMPDB.EMP_ERR1, EMPDB.EMP_ERR2
CHECKPOINT 10000000;

INSERT INTO EMPDB.EMP_TABLE
VALUES
( :EMP_NUM
,:DEPT_NUM
,:FIRST_NAME
,:LAST_NAME
,:SALARY );

END LOGOFF;
LOGOFF;

when can we RESTART fastlaod and cannot?

You Cannot RESTART FastLoad if
The Error Tables are DROPPED
The Target Table is DROPPED
The Target Table is CREATED

You Can RESTART FastLoad
The Error Tables are NOT DROPPED in the script
The Target Table is NOT DROPPED in the script
The Target Table is NOT CREATED in the script
You have defined a checkpoint

Below are fast load commands used for creating fastload scripts:

AXSMOD to specify an access module (e.g., OLE-DB provider) that provides data to the FastLoad utility
on network-attached client systems.

SESSIONS max min to specify the number of sessions. max = maximum number of sessions that will be
logged on.

ERRLIMIT to control a runaway error condition, such as a mis-definition of the input data.
Specify the maximum number of error records you want to occur before the system issues an ERROR and
terminates the load.

TENACITY to specify the number of hours FastLoad will try to establish a connection. The default is no
tenacity.
The statement must be placed before LOGON.

SLEEP to specify the number of minutes FastLoad waits before retrying a logon.
The default is 6 minutes. The statement must be placed before LOGON.




Fastload
1) Loads one table at a time
2) It does not load duplicate data.
3) Table should be empty.
4) Runs 2 phases.
5) It does not run in modes.
a) Import mode.
b) Delete mode.
6) It needs 2 error tables.
7) It does not support NUSI table
8) It applies Access lock on target Table during loading.
Multiload
1) Loads up to 5 tables at a time.
2) Does not mind loading duplicate data.
3) Loads the data into the Table whether it can be either empty or full.
4) Runs 5 phases.
5) It runs in 2 modes.
6) It needs 2 error tables, 1 restart log table and 1 work table.
7) It supports NUSI table loading loading.
8) It applies write lock on target Table table during loading.