I think its to keep the extents identifiable within
the segment header block - sort of in the same way
that oracle used to do in the earlier versions (which
limited the extents to 121, 249, 505 etc dependent on
block size)
hth
connor
--- Jacques Kilchoer <[EMAIL PROTECTED]>
wrote: > > -Origi
Title: RE: Locally Managed Tablespace Uniform Extent
> -Original Message-
> From: Miller, Jay [mailto:[EMAIL PROTECTED]]
>
> My understanding was that the main reason to keep the number
> of extents down
> was in case you needed to drop or truncate the table it wo
My understanding was that the main reason to keep the number of extents down
was in case you needed to drop or truncate the table it would take Oracle a
long time to clean up the fet$ table.
I think, and I emphasize that I am not certain of this, that this is no
longer a problem with locally manag
The advice on Metalink is sound in the sense that
using a finite number of extent sizes is a good thing,
but (imho) the choice of sizes for extents is largely
up to you (a point that the article doesn't really
convey).
The key with the uniform extent is avoiding
fragmentation issues; combine that
Jim,
I'm probably a bit extreme here, but, with all due respect
to Steve Adams (because I really do), I wouldn't worry
terribly much about numbers of extents.
Our 8.1.6 production db on Win2k has 8KB block size and
uniform extent size of 1MB in all tablespaces. Our largest
segment stores the ou