Re: Export / Import from 8i to 9i and locally managed tablespace

"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message news:3e93ddc8$0$4843$ed9e5944_at_reading.news.pipex.net...
> "Howard J. Rogers" <howardjr20002_at_yahoo.com.au> wrote in message
> news:euHka.10032$1s1.167071_at_newsfeeds.bigpond.com...
>
> > However, it is true that *if* you select to use ASSM, and you have a 16K
> > block size, then it does indeed give you a 1M extent in autoallocated
LMT
> > rather than anything else. To that extent, I was wrong to suggest ASSM
has
> > no impact whatsoever on extent sizes, and it is perfectly possible that
it
> > is indeed the ASSM use by our original poster that is causing the
> behaviour
> > that he sees.
>
> Interesting, though the original poster is using uniform allocation of
520k,
> not autoallocate and there are no 1m extents sizes anywhere. The initial
> size referred to in dba_segments was 1096K not 1m. However it does suggest
> that the oft repeated statement that autoallocate tablespaces uses sizes
of
> 64k,1m,8m,64m and 256m needs to be qualified with 'but not all of these
> sizes maybe used depending on your database block size'. I wonder what
> happens with 32k block sizes, and if the list of usable sizes changes at
> all.
>

Hi Niall,

The issue here is that without ASSM, the minimum size of an extent is 2 data blocks (which I'm sure many choose as a size of preference).

However with ASSM, Oracle gets a tad grumpy and demands a minimum extent size of 5 blocks, as additional blocks are required to store these precious little bitmaps.

Therefore if you have a 16K block size x 5 blocks minimum, that's 90K minimum so the poor 64K extent size has no hope and so the next size up (1M) is chosen.

Cheers

Richard Received on Wed Apr 09 2003 - 08:32:39 CDT