RE: LOCALLY MANAGED EXTENT PERFORMANCE

  • From: "MacGregor, Ian A." <ian@xxxxxxxxxxxxxxxxx>
  • To: <tim@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 25 Apr 2005 14:48:49 -0700

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@xxxxxxxxxxxxx =
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Gorman
Sent: Monday, April 25, 2005 12:22 PM
To: oracle-l@xxxxxxxxxxxxx
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@xxxxxxx 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@xxxxxxxxx>
> To: <oracle-l@xxxxxxxxxxxxx>
> 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
> --
> //www.freelists.org/webpage/oracle-l
>=3D20

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

Other related posts: