"Howard J. Rogers" <dba_at_hjrdba.com> wrote in message news:<a5u9is$1r7$1_at_lust.ihug.co.nz>...
> There *is* such a thing, of course... there is an 'autoallocate' policy for
> locally managed tablespaces, and as best I can tell it goes something like
> this:
>
> The first 16 extents of a segment will be 64K in size.
> The next 64 extents will be 1M in size
> Then extents become 8M in size.
> At the 200th extent, you get 64M extents.
> After that, I can't tell you... because I ran out of disk space!
>
> What Daniel is hinting at, I guess, is that having odd-sized extents within
> a tablespace is not a good idea, because it risks fragmentation. I agree
> with him that 'autoallocate' is not a terribly good idea for your own
> tablespaces, and that you should take charge of the extent allocation
> policy.
>
> The essential feature of locally managed tablespace is that we no longer
> really give a damn how many extents a segment acquires, because extent
> allocation is now a trivial operation for the database (though I agree that
> having the extent map for a segment fit into one block makes for some small
> performance improvement, and therefore limiting the number to the old hard
> limits (121 for 2K blocks, 504 for 8K blocks and so on) is still not a bad
> idea).
>
> Regards
> HJR
> --
> ----------------------------------------------
> Resources for Oracle: http://www.hjrdba.com
> ===============================
>
Howard, thanks for posting your findings. I find the results
interesting, and potentially good to have in the back of my mind in
case I encounter auto extent in use. I perfer to either use uniform
extents or manage them manually using a limited set of extents, but
you never know what you will encounter.
Received on Mon Mar 04 2002 - 11:05:52 CST
