Re: Algorithm for calculating extent size in LMT

I think that's a mistake I corrected in the Errata on the chapter. The figure is true for temporary tablespaces (which a load of bits to associate each extent with an instance in OPS/RAC - does anyone know the notional limit on RAC instances - it may be 255 because of this temp space byte, or could be 2 ^ 15, I guess) but the figure is MUCH larger for ordinary LMT's which really do use one bit per extent.

A possible issue with Oracle 9 and automatic undo is that the undo segment header keeps an extent retention map (last commit time per extent in seconds since 1/Jan/1970). If this doesn't have an overflow somewhere, then there is a critical limit on extents where everything could go pear-shaped.

--
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


Yong Huang wrote in message ...


>Is this because the number of extents in the LMT goes above 30,000?

>Jonathan's book p.155 says the 64K bitmap header corresponds to 27,000

>to 30,000 bits. Not sure how this is calculated. But he says if 64K is

>used up because you have too many extents, another map is created in

>the middle of the datafile and space management performance suffers a

>little.

>

>Yong Huang

>yong321_at_yahoo.com