Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Plotting Statspack data

RE: Plotting Statspack data

From: <>
Date: Fri, 5 Mar 2004 09:34:39 +0800
Message-ID: <>

    Thanks Dennis. I have the book and I really put Mr. Millsap's word regarding that issue in
my head (the Method R thing) = ) . My bosses just views effective performance diagnosis
can be achieved ENTIRELY by analyzing systemwide statistics. To be honest, I have
doubts with this project and I guess i'm doing this just to give them good night sleeps
thinking that there's an automated mechanism that will tell them when the database
needs to be fine tuned. How I wish I could tell them that such a mechanism already exists:
the users and their email clients (or phone if they can't really take their program's response
time = )). I'm not implying, though, that statspack data is worthless... I've used it a lot in my entire
career as a DBA and it helped 100% of the time.

   Thanks guys!

PS some people are emailing me about products that make use of statspack data.

       Boy, have I forgotten that there are lots of it already...

03/05/2004 03:42 AM
Please respond to oracle-l  

        To:     "''" <>
        cc:     (bcc: Rhojel Echano/Manila/PH/SGS)
        Subject:        RE: Plotting Statspack data


    I think you should also consider whether this project will be useful. STATSPACK only produces statistics aggregated by instance. Cary Millsap in his new book Optimizing Oracle Performance does a great job of pointing out
why many problems can't be found by this method and it may even lead to making wrong decisions that reduce performance.

Dennis Williams
Lifetouch, Inc.

-----Original Message-----

[]On Behalf Of
Sent: Thursday, March 04, 2004 11:47 AM
Subject: Re: Plotting Statspack data

See at


PS. Please use paragraphs. I hope I am not the only person that finds your post difficult to read.


Sent by:

 03/04/2004 12:34 AM
 Please respond to oracle-l  

        Subject:        Plotting Statspack data

Hi Guys,

I want to hear your comments regarding this present endeavor of mine....

My bosses wants to see some form of automated "database performance indicator reporting" scheme. They want me to create some form of "early warning device" from this kind of scheme, that is, based on certain metrics
and some predetermined threshold values, the scheme would notify the admins
(including me) if the database needs tuning. I talked to my boss and it was
clear to me that he was thinking of ratios (I guess he stopped learning about the Oracle RDBMS after 7.3 ;-)). I explained to him the current paradigm being used by most Oracle DBA's today (I hope) in diagnosing database performance, i.e. wait events analysis. And I told him that the metrics that can tell us systemwide performance is provided by Statspack which is implemented in our site. So, in order to deliver to my bosses this
scheme that they wanted, I thought of plotting statspack data using RRDTool.
This is different from what Mr. Burleson did in his book , however. What I did is I generat ed the values that SPREPORT will produce in its output (specifically the "load summary -- per transaction metrics", "instance efficiency percentages", and "top 5 wait events" sections), store it in the
database, and plotted it to show daily, weekly, and monthly "trends". The statistics are generated daily for two snapshots (with one hour interval, i
know this is quite long) taken during operation peak period. So how I got around the "treshold" values that they demanded? I told them that a baseline
will be determined, and metrics that shoots up or down dramatically against
this baseline will be investigated.

I just want to know your thoughts on this. I've been so immersed on this project that I may be missing some important points. = )


Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.

Archives are at FAQ is at

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.

Archives are at FAQ is at
Received on Thu Mar 04 2004 - 19:39:40 CST

Original text of this message