Re: LOCALLY MANAGED EXTENT PERFORMANCE

>From a production-support perspective...

For years, we've been using a script that would alert if any segments in a tablespace are going to run out of space within "N" extents (i.e. 5, 10, whatever). How do you do this for autoallocate tablespaces?

I know that some folks have reverse-engineered the sizing algorithm for autoallocate, but I don't think it is yet documented anywhere. Which means that Oracle can feel free to "tweak" it whenever they wish...

...which means lots of pages in the middle of the night...

on 4/24/05 8:53 PM, Tanel P=F5der at tanel.poder.003_at_mail.ee wrote:

> Hi,
>=20
> I haven't read the whole thread - but I'd just like to contribute the fac=
t,
> that nowadays I save my time and create all tablespaces as autoallocate -
> and haven't seen any performance nor other problems so far. And I don't
> worry about the number or size of extents at all.
>=20
> Tanel.
>=20
> ----- Original Message -----
> From: "Tim Gorman" <tim_at_evdbt.com>
> To: <oracle-l_at_freelists.org>
> Sent: Sunday, April 24, 2005 8:44 PM
> Subject: Re: LOCALLY MANAGED EXTENT PERFORMANCE
>=20
>=20
>> Exactly why might a large number of extents be a bad thing? In other
>> words,
>> are you sure you are attaching the proper level of importance to the
>> issue?
>>=20
>> To help figure out if this is true, can you describe exactly what
>> operations
>> might be affected by the number of extents, and how? Queries?
>> Inserts/updates/deletes? Truncates? Drops? Monitoring queries?
>>=20
>> And, are you certain that autoLMT resolves the problem of "too many
>> extents"? Isn't there an upper limit on extent size even with autoLMT?
>> If
>> so, then how is this different from intelligently sized uniform LMTs?
>>=20
>> My apologies for the Socratic questioning, but this thread contained too
>> many assertions that need a little more examination...
>=20
> --
> http://www.freelists.org/webpage/oracle-l
>=20

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