Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Looking for a good way to convert from dictionnary manged TBS to Locally managed ones

Re: Looking for a good way to convert from dictionnary manged TBS to Locally managed ones

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Sat, 20 Mar 2004 06:52:43 +1100
Message-ID: <405b4f8f$0$3954$afc38c87@news.optusnet.com.au>

"Bib Endum" <gd-newsgroups_at_spamex.com> wrote in message news:2tE6c.20652$Eb6.500740_at_news20.bellglobal.com...
>
> "Howard J. Rogers" <hjr_at_dizwell.com> a écrit dans le message de
> news:405a78c3$0$8355$afc38c87_at_news.optusnet.com.au...
> >
> > "Daniel Roy" <danielroy10junk_at_hotmail.com> wrote in message
> > news:3722db.0403181919.3162bf41_at_posting.google.com...
> > > > It has been argued and demonstrated here that UNIFORM is of little
use
> > > > and AUTOALLOCATE is the way to go, as this will make sure all
extents
> > > > are properly sized.
> > > >
> > > Can I ask where this has been "argued and demonstrated"? I've been
> > > using uniform, and I'm quite happy with the result. I also group the
> > > objects in tablespaces depending on their expected size (extents 8K,
> > > 16K, 32K, ...).
> > >
> > > Daniel
> >
> > It's been discussed here quite recently, with Richard Foote posting an
> > interesting test demonstrating that autoallocate is extremely difficult
to
> > fragment, and is extremely smart about the way it allocates space to
> > objects. I'm sure you could hunt for it on Google. It would be within
the
> > last two months.
> >
>
> Difficult to fragment because of "fixed multiples" extent sizes ? I mean,
> even if they are not the same, they (almost) all can be reused ?

Yes. In autoallocated LMTs you get 64K, 1M, 8M, 8M, 64M and 256M extents allocated. But under the hood, everything is allocated in 64K units. So when you vacate an 8M 'hole' (dy dropping a table, for example), a lot of 64K free extents are created. If another table wants 64K, it can take it from this new 'pool'. If something wants a 1M extent, it can also use this 'pool'. And so on.

What Richard also demonstrated was that if there are 8 1M 'holes' scattered through the tablespace, and your table requests a single 8M extent, the autoallocate algorithm is smart enough to spot that it can satisfy the request by allocated eight 1M extents.

Ultimately, because you have different extent sizes, you could find yourself with a 64K 'hole' when everything within the tablespace is now requesting 1M, and that would count as fragmentation. But you have to push it hard before that ever happens or becomes a serious issue.

Regards
HJR Received on Fri Mar 19 2004 - 13:52:43 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US