Home Page for the TeradataForum

Archives of the TeradataForum

Message Posted: Sun, 02 Mar 2008 @ 10:56:05 GMT

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

Subj:   Re: MLOAD application phase
From:   Dieter Noeth

OmerAl wrote:

  1. We have only 7 AMPs and at any point in time we have MAX 4-5 MLOADS running. The number of sessions never exceed the number of AMPs.  

Running 4 to 5 MLoads on a single node system will result in 100% system usage. The number of MLoad/FastLoad sessions can't be greater than the number of AMPs.

  3. We are not using FILLER.  

Fillers, large rows, VarText and Checkpoints might slow down the Acquisition, but not the Application phase. According to the posted log Acquisition phase was 30 seconds, but Application phase 30 minutes.

  6. The loading table is not used at all. There are other tables that query the source table at the same time.  

You export and MLoad? Did you try a simple Insert/Select instead?

  In addition the UPI is defined correctly without any SKEW and there are only INSERTS. This is what surprises me even more.  

UPI means no dup row checks

  Also, I simulated the situation in our DEV env and it took 1.5 HR. Later I realized that it took longer because we did not run collect stats in dev env whereas we run collect stats daily in prod.  

Stats will not change the runtime for any kind of insert/update/delete or MLoad an a table.

I'd guess that it's mainly because of:

1. parallel MLoads

2. loading just a small number of rows. Mload is only efficient, if the number of modifications per datablock is greater than 1.

417.665 out of 100.000.000 is just 0.42 percent, TPump (even BTEQ) might deliver better performance.

Is the target table partitioned? Loading into just 1 or a few partitions might speed up the load.


  <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: 28 Jun 2020