| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Capacity Planner from OEM VS Statspack
I agree with Babette. I have had some situations where the database "hung".
If you are the only DBA, things get hairy fast. Phone ringing off the hook,
people standing around your desk asking questions like "should we bounce
Oracle?". Metalink has a nice note on hanging, by the way. You don't know
how long the situation will continue. Will it clear up by itself in a few
minutes, or should you just bounce the database so everyone can get back to
work? Usually you can't diagnose the problem on the spot. I found GUI tools
poor in this situation because the GUI itself gets really slow and now
you're ignoring your bosses to peer into your screen.
Yes, if the problem recurs often enough, a 10046 trace may be great. But your goal is to diagnose the problem without having the problem recur. All your system queries are returning really slowly so figuring out which process is at fault (if it is only one) takes an excruciating amount of time under pressure because the queries return realllllly slooooly.
I found STATSPACK great in the database hanging situation. You just take a snapshot, calm the people for 5 minutes, then take another snapshot. When people ask whether the database should be bounced, you can reply that you want to take another snapshot in 5 minutes and if the situation hasn't cleared by then, we'll bounce it. By default STATSPACK will collect enough information to allow you to drill into the situation and diagnose the problem.
Nothing irritates management like saying "I don't know why the situation occurred, I couldn't collect enough information to diagnose the problem and prevent it from recurring".
Oh, one correction for Babette -- I would say 4 things: CPU, disk, network, and memory.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com]
Sent: Thursday, February 05, 2004 2:33 PM
To: oracle-l_at_freelists.org
Subject: RE: Capacity Planner from OEM VS Statspack
Babette,
Have you done a 10046 trace on this?
Jared
<babette.turnerunderwood_at_hrdc-drhc.gc.ca>
Sent by: oracle-l-bounce_at_freelists.org
02/05/2004 11:47 AM
Please respond to oracle-l
To: <oracle-l_at_freelists.org>
cc:
Subject: RE: Capacity Planner from OEM VS Statspack
It is worse than that .....
EVERYONE has noticed that at times the performance is abysmally slow. BUT according to all of the mainframe reporting information=20 Everything is fine... No swapping, no paging, no disk bottleneck, no = memory problems, no CPU problems.....
For instance, full tablescan (no indexes) to update a NULL column to =
NULL
on 1 Million rows. Can take up to three times as long at times.
BUT System people insist there is nothing being pushed at the system =
level.
The CPU is not maxed out, the disks have no bottlenecks or contention =
and there are no memory problems at this time.
There are only three things, CPU, DISK, Network. There has to be something wrong with at least one of them to be getting = the weird sporadic performance that we get.
It is hard to get overall picture of health of machine in MF =
environment.
We have Logical machines (LPARs) on a single physical box.
I know that I/O on other LPARs can affect our I/O, but we are told that =
there are no problems according to the system records.
The statspack information is a bonus. We have SOMETHING that we can say = "explain this". Still waiting on explanation for a few weeks now...
Babette
-----Original Message-----
From: oracle-l-bounce_at_freelists.org =
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Niall Litchfield
Sent: 2004-02-03 3:21 PM
To: oracle-l_at_freelists.org
Subject: RE: Capacity Planner from OEM VS Statspack
> I agree with Ian.... Sometimes Statspack is VERY useful..
>=3D20
>=3D20
>=3D20
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 =3D
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 =
=3D
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 =
=3D
not
that last one. Almost never does anyone whinge that 'the system is =3D
slow', or
at least when they do they have a specific example in mind. As a result =
=3D
I am
definitely biased towards a view that systems don't experience problems =
=3D
-
processes do. I *suspect* that even where the *system* is slow then =3D
actually
it will be fewer than 5 processes that are killing it, but have no =3D
proof.=3D20
Niall
-- 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_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 ----------------------------------------------------------------- ---------------------------------------------------------------- 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 ----------------------------------------------------------------- ---------------------------------------------------------------- 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 Thu Feb 05 2004 - 14:54:17 CST
 |
 |