Re: LOCALLY MANAGED EXTENT PERFORMANCE
- From: jungwolf <spatenau@xxxxxxxxx>
- To: tim@xxxxxxxxx
- Date: Mon, 25 Apr 2005 17:04:30 -0500
On 4/25/05, Tim Gorman <tim@xxxxxxxxx> wrote:
> Doesn't do the job. This only tells me what the largest extent sizes are
> for segments. It does not tell me whether any of them are possible to ru=
n
> out of space within "N" extensions...
Assuming autoextention on the datafiles, why are you worrying about
how many extents until you run out of disk space? It seems to me that
it now makes more sense to keep on eye on disk space itself. Unless
you are trying to run your mountpoints to 99% full or you have small
mountpoints, ask the sysadmins to set a warning at X% and an alarm at
Y%.
In other words, it made sense to keep track of extents when a single
extent was a significant percentage of the disk space. In these days
of SANE on SAN/NAS and large virtual disks, large extents of 100MB or
even 512MB are less than 1% of, say, a 73GB disk. I'd rather see "30%
space free" than "space for 50 extents".
Even if you don't have autoextend on for datafiles, you can take a
look at the amount of free space in a tablespace in terms of GBs or
percentage. "I'm down to 5% free on my 20GB tablespace. Time to add
some more."
You mentioned:
"My view on it: autoallocate is OK for very small applications where space
just doesn't change very rapidly. When space management is important, it i=
s
worth the time to use LMT uniform intelligently."
My view is actually the other way around: autoallocate is ok for
large applications, both were space is static and where space changes
very rapidly. The percentage of space wasted by autoallocate
decreases as the amount of data grows large. And for rapidly changing
table sizes, the increasing size of extents takes away the issues when
the size of an object is estimated incorrectly.
Steven
--
//www.freelists.org/webpage/oracle-l
Other related posts:
