Home Page for the TeradataForum

Archives of the TeradataForum

Message Posted: Tue, 23 Oct 2007 @ 16:18:34 GMT

  <Prev Next>   <<First <Prev Next> Last>>  

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".


  <Prev Next>   <<First <Prev Next> Last>>  
  Top Home Privacy Feedback  
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 15 Jun 2023