 |
 |
Archives of the TeradataForum
Message Posted: Tue, 23 Oct 2007 @ 16:18:34 GMT
| Subj: | | Re: Unexpected behavior in Fastload |
| |
| From: | | Dieter Noeth |
Shubhangi Pararha wrote:
| | I'am experiencing one unexpected behavior in Fastload. | |
| | I wanted the records with the latest update date to be loaded in my target table and the rest of the records to go to error table
2. | |
| | ...
So, I sorted the file, in descending order with the Address update date field using the SYNCSORT in mainframes. | |
| | ...
*Also, in whichever order I sort, the records with the changed value (the fields which I changed) go to the Error Table 2. It appears that the
Fastload is not loading the record as read in the file.* | |
That's right.
Sorting is a waste of mainframe resources, because FastLoad doesn't know about that order when it's doing the actual inserts. No information of
record numbers within the input file is stored. This is one of the reasons, why there's almost no overhead in perm Space when loading with
FastLoad, 100GB perm space used during load for a 100GB table size after load.
| | Fastload while determining the duplicate record, sees all the fields or only the fields which we are loading in the targert
table? | |
Only the fields you actually store in the target table.
| | Will these be treated as Duplicate records or UPI voilation? | |
Duplicate rows.
If you want to maintain that "latest update date record" you'll have to use MultiLoad, which exactly knows about record numbers and applies all
changes "in order".
Dieter
| |
