Archives of the TeradataForum

Message Posted: Thu, 10 Apr 2003 @ 18:01:29 GMT

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

Hi there,

Follow these basic observed MLOAD performance rules and try to locate your problem creating point.

1) Determine which phase of the MultiLoad job is causing the poor performance. If it is during the acquisition phase, when data is acquired from the client system, the problem may be with the client system. If it is during the application phase, when data is applied to the target tables, the problem is not likely to be with the client system.

The MultiLoad job output lists the job phases and other useful information. Save these listings for evaluation later.

2)Use the Teradata RDBMS Query Session utility to monitor the progress of the MultiLoad job.

3)Check for locks on the MultiLoad target tables:

* Use the Teradata RDBMS Show Locks utility to check for Hut locks.

* Use the Query Session utility or other utilities that use the performance monitor feature of the Teradata RDBMS (Teradata Manager, Amon, or Pmon) to check for the "blocked" status, indicating transaction locks.

4)Check the DBC.Resusage table for problem areas, such as data bus or CPU capacities at or near 100 percent for one or more processors.

5)Determine whether the target tables have NUSIs. NUSIs degrade MultiLoad performance because the utility builds a separate NUSI change row to be applied to each NUSI subtable after all of the rows have been applied to the primary table.

6)Check the size of the error tables. Write operations to the fallback error tables are performed at normal SQL speed, which is much slower than normal MultiLoad tasks.

7) Verify that the primary index is unique. NUPIs can cause severe MultiLoad performance problems.

Regards,

Vishal G.

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