RE: LOCALLY MANAGED EXTENT PERFORMANCE

What I do is to track the growth of a segment and thus have data for a = day, week, month, three months, six months, nine months, and one year. = If I don't have figures, predictions are made. I send a warning if = there is less than a month's worth of space for a segment.

The only trouble with this system is, I expect it becomes unusable if = your database has a very large number of objects.

Ian=20

-----Original Message-----
From: oracle-l-bounce_at_freelists.org =
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Gorman Sent: Monday, April 25, 2005 12:22 PM
To: oracle-l_at_freelists.org
Subject: 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=3DF5der at tanel.poder.003_at_mail.ee wrote:

> Hi,
>=3D20
> I haven't read the whole thread - but I'd just like to contribute the =
fac=3D
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.
>=3D20
> Tanel.
>=3D20
> ----- 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
>=3D20
>=3D20
>> 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?
>>=3D20
>> 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?
>>=3D20
>> 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?
>>=3D20
>> My apologies for the Socratic questioning, but this thread contained =
too
>> many assertions that need a little more examination...
>=3D20
> --
> http://www.freelists.org/webpage/oracle-l
>=3D20

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