RE: Capacity Planner from OEM VS Statspack

From: Niall Litchfield <niall.litchfield_at_dial.pipex.com>
Date: Tue, 3 Feb 2004 20:20:44 -0000
Message-ID: <002201c3ea93$358f9440$ea97bc3e@nlhome>

> I agree with Ian.... Sometimes Statspack is VERY useful..

>=20

> In our case the Statspack reports shows ave read times of=20
> 1-10ms. However we occasionally see read times of 300-700 ms.

>=20

> We are currently investigating what is on the slower disks,=20
> What systems are sharing them, and whether oracle is=3D20=20
> chaining I/O requests and giving false stats or if there=20
> really is a =3D problem. (Hey, on OS/390 mainframe system we=20
> don't get iostat / sar / vmstat / =3D
> top)

>=20

> This top-down approach doesn't address any SPECIFIC=20
> performance proble. BUT ... if we didn't have Statspack=20
> running periodically, we might have =3D missed this.
>=20
> - Babette

I think the interesting question here is 'If you had missed this, would anyone care?' and its corollary 'now you have caught it, does anyone = care?'.
Now I admit that I have a biased view in that all anyone ever seems to complain to me about is 'Screen X is running slow' or 'we can't complete = our
management reports overnight' or 'I'm not a dba so your presentation on managing databases that I chose to attend was irrelevant' - oops sorry = not
that last one. Almost never does anyone whinge that 'the system is = slow', or
at least when they do they have a specific example in mind. As a result = I am
definitely biased towards a view that systems don't experience problems = -
processes do. I *suspect* that even where the *system* is slow then = actually
it will be fewer than 5 processes that are killing it, but have no = proof.=20

Niall

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_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
-----------------------------------------------------------------

Received on Tue Feb 03 2004 - 14:20:44 CST