Re: Statspack ratios help
- From: Mogens Nørrgaard <mln@xxxxxxxxxxxx>
- Date: Thu, 08 Jun 2006 07:28:28 +0200
You can say that again :).
First of all, I think it's time the Subject of this thread changed from
the wrongful statement 'Statspack ratios help' to 'Statspack ratios help
consultants' (because consultants are paid by the hour, not by the
solution).
Second, I think your last sentence should be shortened:
"....I find the data in the Wait Events/CPU Usage useful." :-)))
The on-one-hand-but-then-again-on-the-other-hand arguments we're seeing
in the thread speak louder than Word.
I often hear the argument that people know Statspack might not <insert
various things here>, but on the other hand they HAVE to make do with it
since <insert various arguments here>.
When so many good people in our circles try for decades to come up with
examples where Statspack really, conclusively, honestly came up with
answers instead of questions ... you have to ask yourself a few
questions if you're an enquiring mind.
Workload reduction (find some heavy SQL, do something, repeat) can be
good, clean fun, and it will sometimes keep you off the streets even
after dark, but in very many cases it's not the thing that fixes a
certain, bad user experience. When it is, it's often by way of a
butterfly wings effect or just pure luck/chance.
Mogens
Terry Sutton wrote:
Cary, hope you didn't hurt yourself falling overboard. :-)
Yes, I misspoke. I did mean that having soft parses is better than having
the same number of hard parses, but obviously having almost as many parses
as executions is not good. I should have stuck with my initial statement.
Ratios don't tell you much.
While I think more highly of Statspack data than Cary does (partly because I
often wind up having to work with that data, without the ability to profile
a specific process), I find the data in the Wait Events/CPU Usage section
much, much more useful than the ratios.
--
//www.freelists.org/webpage/oracle-l
Other related posts: