Return-Path: <oracle-l-bounce@freelists.org>
Received: from air189.startdedicated.com (root@localhost)
 by orafaq.com (8.11.6/8.11.6) with ESMTP id i130jJO03258
 for <oracle-l@orafaq.com>; Mon, 2 Feb 2004 18:45:19 -0600
X-ClientAddr: 206.53.239.180
Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180])
 by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i130jGo03249
 for <oracle-l@orafaq.com>; Mon, 2 Feb 2004 18:45:16 -0600
Received: from turing (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP
 id 8BB3D394EEC; Mon,  2 Feb 2004 19:41:05 -0500 (EST)
Received: with ECARTIS (v1.0.0; list oracle-l); Mon, 02 Feb 2004 19:40:04 -0500 (EST)
X-Original-To: oracle-l@freelists.org
Delivered-To: oracle-l@freelists.org
Received: from mail.sagelogix.com (unknown [69.15.85.3])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id 63DDD394DCB
 for <oracle-l@freelists.org>; Mon,  2 Feb 2004 19:39:54 -0500 (EST)
Received: (qmail 3919 invoked from network); 3 Feb 2004 00:35:52 -0000
Received: from unknown (HELO ocs.sagelogix.com) (192.168.25.20)
  by 0 with SMTP; 3 Feb 2004 00:35:51 -0000
Received: from 0-1pool101-182.nas37.thornton1.co.us.da.qwest.net by ocs.sagelogix.com
 with ESMTP id 64051075744137; Mon, 02 Feb 2004 10:48:57 -0700
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Mon, 02 Feb 2004 10:50:23 -0700
Subject: Re: Capacity Planner from OEM VS Statspack
From: Tim Gorman <tim@sagelogix.com>
To: <oracle-l@freelists.org>
Message-ID: <BC43DBEF.F86B%tim@sagelogix.com>
In-Reply-To: <AFF54B073FF15849B53E32E67EE860763A7C72@ENHBGPRI11.PA.LCL>
Mime-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-archive-position: 613
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-To: oracle-l-bounce@freelists.org
X-original-sender: tim@sagelogix.com
Precedence: normal
Reply-To: oracle-l@freelists.org
X-list: oracle-l

With all due respect, I disagree with the assertion that aggregate
statistics are useless.  While aggregated statistics have problems in
pinpointing specific problems (which isn't their intent anyway), they can
point the way toward problems in a general fashion, while serving admirably
to debunk groundless speculation as well.  The fact is that aggregated
information and specific information provide a continuity to be used in
tandem, and they should each be understood for their strengths and
weaknesses.

Take political campaigns as an analogy.  While media polls do not provide
information about why people vote, they most certainly do accurately predict
how the vote will tally.  If you want to know why, you talk to individuals.
If you want to know the trend, you poll masses.  Trends cannot be detected
from individual interviews any easier or more accurately than specific
causes can be detected from mass polling.

With the volume of misinformation about the causes of performance problems
on Oracle-based systems, it is helpful to have information at hand going
back over a period of time that points towards certain problems and
conclusively eliminates others.

Keeping management off one's back should not be underrated.  IT management
is eminently capable of wasting vast amounts of time and effort due to
something read in a magazine or heard from a friend "in the know".
Countering the gibberish with fast facts is helpful in keeping an
organization focused on what is vital.

Personally, I spend a fair amount of time applying data warehousing
techniques to the data collected by STATSPACK, in addition to reading trace
files.  I use both tools, each where applicable.  If I had to choose one
tool or the other exclusively, then I agree that tracing is much more
accurate and can feasibly be adapted to trend analysis if necessary.  But I
don't have to choose, so I prefer to use the best tool for the task at hand.

In statistical analysis terms, analyzing trace files is "directed analysis",
requiring preparation and prior direction.  Using the same terms, analyzing
collected aggregated statistics is "undirected analysis", which can be
performed before a direction is given or even known.  Another broad term for
undirected analysis is "data mining", although that is certainly too
grandiose a term for STATSPACK and completely unsuitable for the default
report provided by STATSPACK.

Just my $0.02... 

-Tim


on 2/2/04 7:32 AM, Freeman, Donald at dofreeman@state.pa.us wrote:

> I'm a relatively new DBA but I have 30 years electronic engineering =
> experience.  I'm used to tools that work and actually measure what they =
> purport to. I got all excited about the capacity planner about 6 months =
> ago and asked the same questions you are asking now.  Mostly, nobody is =
> using it.  It becomes a headache itself, the agent fails and causes you =
> grief.  I don't think you'll find much usefulness in it.  When you start =
> troubleshooting it won't give you anything helpful.=20
> 
> After reading Carey Milsaps Optimizing Oracle Performance I am less than =
> thrilled with statspack also.  You can't solve (or even determine) a =
> particular problems origin while looking at aggregate values.
> 
> The main value of these things is to provide a comfort level and =
> distraction to management.  Attach your statspack report to an email and =
> send it to your boss.  It should keep him (or her) busy for some time =
> while you work on the database.
> 
> 
> 
> -----Original Message-----
> From: oracle-l-bounce@freelists.org
> [mailto:oracle-l-bounce@freelists.org]On Behalf Of
> Luc.Demanche@astrazeneca.com
> Sent: Monday, February 02, 2004 9:19 AM
> To: oracledba@lazydba.com; oracle-l@freelists.org
> Subject: Capacity Planner from OEM VS Statspack
> 
> 
> Hi DBA,
> 
> I'm starting to take a look at the "Capacity Planner" tool from the
> Diagnostics Pack.
> Great tool, collects info on lots of interesting statistics ... =20
> from databases=20
> - Response time
> - Wait events
> - I/O
> - Storage=20
> - ...=09
> and servers
> - CPU
> - Memory
> - File system
> - ...
> =20
> Good Report tool, create graphics and you can even do a trend=20
> analysis...=20
> 
> I have two questions:
> 1- Are a lot of you using it?
> 2- Does STATSPACK become less usefull?  I would keep STATSPACK for the =
> SQL
> level.  Capacity Planner doesn't seem to handler that level.  Right?
> 
> Thanks
> Luc
> 
> 
> ---------
> Luc Demanche
> AstraZeneca R&D Montreal
> Oracle Database Administrator
> 514.832.3200 x2356
> 
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request@freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request@freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

