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.

Dieter


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

Attachments

Library

Quick Reference