RE: Awr waits over 100%

  • From: "Kenneth Naim" <kennethnaim@xxxxxxxxx>
  • To: "'Wolfgang Breitling'" <breitliw@xxxxxxxxxxxxx>
  • Date: Thu, 29 Sep 2011 01:11:33 -0400

I understand that that due to the number of processors and waits that db
time will and should exceed the elapsed time in a busy system. I've it as
high as 3 times the processors time the elapsed time. But shouldn't the
waits + cpu time be divided by the db time so it can't never exceed 100%
unless it is double counting like Marcus said. If it were dividing by the
elapsed time then it would routinely go over 100% but that isn't the case in
hundreds of awr's I've looked at over the years. It begs the question isn't
the double counting a bug? I'd understand if it was minor to rounding but to
be off by such a high number makes the understanding the top 5 issues
deceptive as one doesn't know how off they are and if they are in the
correct order which leads to incorrect analysis and solutions.

-----Original Message-----
From: Wolfgang Breitling [mailto:breitliw@xxxxxxxxxxxxx] 
Sent: Wednesday, September 28, 2011 6:26 PM
To: kennethnaim@xxxxxxxxx
Cc: oracle-l
Subject: Re: Awr waits over 100%

To add a bit more, on a busy system it is even possible that productive work
( CPU time ) "appears" to be > 100% according to AWR.

Wolfgang Breitling
Centrex Consulting Corporation

On 2011-09-28, at 12:19 PM, Wolfgang Breitling wrote:

> I'd consider that "normal"
> While a system has only a limited ( to the number of cpus/cores ) capacity
for productive work, any system has an unlimited capacity to wait.
> E.g. if one session holds a lock for 1 hour and 2 sessions wait for that
lock fthen you may have up to 100% ( 1 hour in 1 hour ) cpu usage from that
one session and 200% ( 2 hours in 1 hour ) waits from the other 2 sessions.
> Regards
> Wolfgang Breitling
> Centrex Consulting Corporation
> On 2011-09-28, at 8:55 AM, Kenneth Naim wrote:
>> I pulled an awr this morning for a period and the top wait events add 
>> up to almost 200%. I was curious if anyone saw this before. I've seen 
>> it slightly over 100% that I wrote off for rounding but never saw it 
>> so high. I'm addressing the actual wait events so no issues there.
> --


Other related posts: