Comments on: Analysing Statspack (7)

By: xpchild » analysing statspack 7

xpchild » analysing statspack 7 — Sat, 30 Jul 2011 07:14:59 +0000

[...] 原文：http://jonathanlewis.wordpress.com/2007/10/23/analysing-statspack-7/ [...]

By: Robert

Robert — Wed, 31 Oct 2007 12:13:12 +0000

This is pretty much what Millsap and Holt write in their “Optimizing Oracle Performance”: you cannot extract detail from a aggregated value. Which is perfectly logical but reminding people is probably a good idea since often only these aggregated values are looked at. (Speculation: maybe it’s because they are easier available.)

By: Pierre Roussin

Pierre Roussin — Thu, 25 Oct 2007 10:01:44 +0000

To me it looks like a not so badly tuned db, I compared your figures to similar figures I got from a 255 users Siebel database before I started to tune it. So speculatively:
Indexes need to be rebuilt possibly to remove buffer busy waits;
sequential read contentions in the cache, lots of concurrency;
they might not be using ASSM;
check point incomplete needs to fixed evidently;
if there are 16 cpu’s there could be a lack of RAM.
P.

By: Gary

Gary — Wed, 24 Oct 2007 00:32:42 +0000

The PL/SQL lock timer suggests 4,077 one-minute ‘sleeps’ which might be associated with a batch job timed to pick up from a queue. It also suggests 68 hours if there was one job doing all the waiting, and nothing else, and it was running all the time. That is a multiple of the 17 hours you get as a minimum time for 16 CPUs. Maybe there were only 4 CPUs and it was a 68 hour interval, with CPUs maxed at a constant 100%. As you say, pure conjecture.