initial and next extent

Quote:

---

Originally posted by jmodic

Quote:

---

Originally posted by nagarjuna
But, the bulk inserts are slower in LMT compared with DMT (dictionary managed tablespace).

---

How did you come to that conclusion? Can you elaborate this a bit further?

---

This is not documented. This can be learn by experiance. Try creating two tablespaces of sizes 5gbs. One as LMT and other one as DMT. The try inserting huge amount of data. Other things being equal, the insertions in LMT takes more time. Try it out. Usually 30% more time than that of DMT.

-nagarjuna

I can not afford to play around with 10GB space in any of my testing instances, however I'm sure there are bits and peaces missing in your scenario, if you realy got 30% diference in bulk load performance between LMT and DMT.

For example:

What was the extent size in your LMT set to? Sure, if the bulk load created thousands of extents in LMT, then performance might be worse because of the extended bitmap management (we had discussion about this few days ago in this forum). But if you set your uniform extent size to let's say 1GB, so that the whole 5GB load will fit into 5 extents, then I simply can't belive that LMT will perform anything worse than DMT.

All that bulk load has to do with tablespace organisation is when it has to allocate new extent, that's all.

I said "OTHERS BEING EQUAL"
It means, extents sizes are of same size. I used 16mb extents. All are uniform extents in both LMT and DMT (pctincrease 0)

if you have tried in 9.2.0.1 then most probably slow insert is caused by automatic segment management