Re: LOCALLY MANAGED EXTENT PERFORMANCE

On 4/25/05, Tim Gorman <tim_at_evdbt.com> 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

--
http://www.freelists.org/webpage/oracle-l