ROFL. Yup. That was on my list too. It was also on the Oracle VLDB list for 7.1.
For a while after Oracle declined that enhancement Rightsizing, Inc. was
selling and maintaining EXTMON as a companion to SNAPSTAT for a nominal fee,
but since both were a sets of open scripts and example cron entries quite a few
folks decided unilaterally it was freeware.
EXTMON would have to be updated for non-dictionary maintained space gathering,
but if there is interest I suppose I could do that (I don’t think there is a
point to updating SNAPSTAT what with Tanel maintaining snapper and Oracle
having ASH builtins and ADDM that are cheaper to run [operationally, I’m not
referencing license cost]).
The thing about maintaining a history of extension is that it can seamlessly
accounts for growth and shrinkage as well as new objects and “gone” objects.
And of course in ancient times there was a quite small limit to the number of
extents an object could have…
Just for fun, here is the old product blurb:
EXTMON
Extent growth monitor and history tool
Every DBA hates surprises. With EXTMON working for you, the most common and
least defensible surprise can be a thing of the past: You don’t need to get
caught out of space or with too many extents ever again!
EXTMON lets you know what has extended and keeps a complete history of the
space consuming objects of the database (segments) over time, allowing you to
plan for adding space to tablespaces before you run out!
Although EXTMON can be run frequently enough to serve as a short term monitor
because of the extremely efficient data dictionary queries it employs, the best
use of EXTMON is tracking growth on a daily basis to construct a capacity plan
using real growth history in calendar time.
With EXTMON, you can give an accurate answer in place of a nervous guess to
the question: How much
more disk space will we need next quarter?
EXTMON has a side benefit of announcing newly created objects, so you will
know when objects have been created, even if the creator of the object didn’t
bother with change control procedures. Another surprise eliminated!
No more surprises
EXTMON
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Cary Millsap
Sent: Thursday, November 12, 2015 1:43 PM
To: Upendra N
Cc: Oracle-L
Subject: Re: Segment growth monitoring
Back in Oracle version 6.0.36, I asked in an enhancement request for a
timestamp column in UET$.
Is it still not there? :-)
Cary Millsap
Method R Corporation
Author of <http://amzn.to/OM0q75> Optimizing Oracle Performance and
<http://amzn.to/173bpzg> The Method R Guide to Mastering Oracle Trace Data
Get the MOTD book free (PDF) at method-r.com <http://method-r.com>
On Wed, Nov 11, 2015 at 4:13 PM, Upendra nerilla <nupendra@xxxxxxxxxxx> wrote:
Hello all -
I am trying to track the growth of a few problem tables.. if there is a runaway
process, they might continue to write without dying.. I looked at
dba_hist_seg_stat.space_used_delta, it doesn't seem to be consistent in
tracking the growth. Especially for situations like, if the table gets
truncated or if there are massive deletes, this data doesn't accurately
represent reality..
Any suggestions on how it could be tracked?
Worst case I am thinking of dumping the dba_segment data into a table nightly
to track it. Trying to see if there are better ways to handle this.
Thanks
-Upendra
