Re: Algorithm for calculating extent size in LMT

The key phrase, of course is "their own". It could make sense if you have been given a packaged solution and told not to muck about with tablespace names etc. Some packages that we all know and loathe will then have 1,000 tables in the tablespace, without storage clauses, and grow 5 of them to GB+ whilst leaving 800 of them untouched. In this case Autoallocate is a pretty good damage limitation strategy.

I used to advice people that 0 was the only good value for PCTINCREASE, but at a pinch 100 was a possibly alternative. Oracle have gone one better with their strategy of watching it grow for a bit then slamming it 800%.

It's worth bearing in mind that if you get unlucky, and allocate the first 256MB extent just as the table reaches 'full size', you can "deallocate unused", and shrink the last extent - all the way down to 64K if needs be.

--
Jonathan Lewis
http://www.jlcomp.demon.co.uk

Now running 3-day intensive seminars
http://www.jlcomp.demon.co.uk/seminar.html

Host to The Co-Operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

Author of:
Practical Oracle 8i: Building Efficient Databases


Howard J. Rogers wrote in message ...


>Hi Mark.

>

>I agree.  Uniform size is so easy to do, I can't think why anyone would

want


>to use autoallocate for their own tablespaces (something in the back of my

>head tells me 9i Release 2 uses autoallocate for SYSTEM.  I may have got my

>neurons crossed, though.  And undo tablespaces are autoallocate, of

course).


>

>On the other hand, the autoallocate policy is not as crazy as ye olde

>PCTINCREASE, and the possible fragmentation penalties seem less severe.

>

>Regards

>HJR