Re: Algorithm for calculating extent size in LMT

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

nsouto_at_optushome.com.au.nospam (Nuno Souto) wrote in message news:<3c83682d.4195649_at_news-vip.optusnet.com.au>...
> I won't buy into the "no more problems with LMTs" concept, Howard.
> I'm currently running them in a production system with 8.1.7/NT.
> There are indeed problems. Things slow down dramatically once you go
> over a certain boundary in terms of number of extents. Would love to
> have the numbers for you at the drop of a hat, but I don't.
>
> First noticed the problem with a recursive PL/SQL update that ate up
> the RLB. All the rollback segment traffic became horrendously slow as
> the number of extents used went ballistic. Wasn't full, but there
> were a lot of 16K extents(block size is 8K). I mean a LOT. Boom,
> performance of the system went out the window.
>
> Maybe Jonathan will have some numbers? I can't afford the time to
> chase this up, gotta get this system out by the end of April and no
> time left for experiences. But it's worth doing some research in this
> area.
>
> IMHO, it's not an absolute number. Relative to the size of the
> datafile. Which leads me to believe there is some "sweet" boundary or
> ratio between datafile size, db block size and fixed extent size for
> LMT beyond which things will go "bonk". It's important that someone
> does a little bit of investigative work in this area to make sure we
> don't collectively stick our feet in mud with a real live system. Any
> takers?
>
>
> Cheers
> Nuno Souto
> nsouto_at_optushome.com.au.nospam
Received on Mon Mar 04 2002 - 13:15:25 CST