Archives of the TeradataForum

Message Posted: Wed, 29 Jun 2005 @ 17:37:04 GMT

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

I haven't seen an answer to this yet.

The table must have a poor choice for the primary index which is causing data skew. I bet the multi-load also took a long time to run because of duplicate row checks (NUPI DUPS).

I will try to explain why you cannot move the data because of the skew. First space usage is distributed by vprocs(AMPS).

Here is a an example to explain the problem you are probably seeing. But without knowing the number of AMPS and how much space you were trying to move it cannot be determined.

I will use the case of 10 amps and also assume the tables skewed 100% to one amp for simplicity. Since each amp must have the same amount of space, the database must have 1 gig (10 AMPS * 100 meg) in the database to store the table. You could only move 99 gig away in this situation. My guess is you have many more AMPS so you would have to keep much more space in the database.

The real problem is probably a poor choice of Primary index. Without going into detail, the best choice for a primary index are the column/columns most frequently used in JOINS to other tables and are nearly unique in values. The exception to this rule is for single table Tactical Queries which the PI choice would columns always used in the filter still assuming nearly unique values. Primary index choice for small reference tables is usually the KEY, unless you will need single amp lookups on a description to find the key.

Thanks,

Bob Diehl
Travelcoity.com

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