RE: d/b health check
- From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 25 Aug 2004 11:35:58 -0500
> I knew nothing about it until I was
> onsite - and a user was testing routines after an
> 8.1.7.4 to 9.2.0.4 migration (on a saturday) - during
> actual acceptance testing. "Oh - these hang all the
> time. we just kill the app and restart it."=20
> Well, their zombied session (and others) would still
> be sitting there, holding locks, until PMON would get
> motivated. (yes, they should not have been running on
> win32)."
Exactly. Sometimes you have to be there and see it to know what's going =
on.
But you'll never, ever find out if you're not willing to even listen. =
And
that, I think, is Problem #1 with traditional methods. They don't say it
explicitly, but implicitly, step one is this: "Make the user go away so =
that
you can get busy looking at statistics." :)=20
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *
Upcoming events:
- Performance Diagnosis 101: 9/14 San Francisco, 10/5 Charlotte, 10/26
Toronto
- SQL Optimization 101: 8/16 Minneapolis, 9/20 Hartford, 10/18 New =
Orleans
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx =
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Paul Drake
Sent: Wednesday, August 25, 2004 11:06 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: d/b health check
--- "Daniel W. Fink" <Daniel.Fink@xxxxxxx> wrote:
> Just because no-one is complaining (that you know
> about) does not mean=20
> that nothing is wrong.=20
snip
> Users may become
> conditioned to accept=20
> things the way they are and just complain amongst
> themselves and never=20
> to management or IT.=20
large snip to avoid bouncing
> Just food for thought,
> Daniel Fink
Dan,
I totally agree. Users may be conditioned to beating
their collective heads against the wall.
"that report took too long, so we don't use it
anymore".
there may also be latent time bombs such that when you
upgrade from say 8.1.7 to 9.2 are comperable to an
aneurism bursting.
one site had posting routines running for hours,
frequently hanging - not because they took a long time
to actually execute, but due to the app code causing a
series of serializations which were manifested as
blocked sessions. (users hitting ctrl-alt-del left
around zombies, which on win32 - PMON is notoriously
lazy in actually terminating the thread and cleaning
up the wreckage). I knew nothing about it until I was
onsite - and a user was testing routines after an
8.1.7.4 to 9.2.0.4 migration (on a saturday) - during
actual acceptance testing. "Oh - these hang all the
time. we just kill the app and restart it."=20
Well, their zombied session (and others) would still
be sitting there, holding locks, until PMON would get
motivated. (yes, they should not have been running on
win32).
the routine ran in minutes in single user mode.
One has to assume that the users will not complain
directly about app performance.
You as the dba might not find out about it, until you
hear that the client has moved to a competitive
product, or when you are up in front of a group of
users at a conference and caught offguard.
"they're out there".
Pd
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
