Comments on: AWR oddity

By: Pythian Group Blog » Blog Archive » Log Buffer #70: a Carnival of the Vanities for DBAs

Fri, 09 Nov 2007 18:10:45 +0000

[...] to things Oracle, Jonathan Lewis’s Oracle Scratchpad has an item on an AWR oddity. No, not its licensing terms, it’s a discrepancy between time stats as reported by statspack [...]

By: Jonathan Lewis

Jonathan Lewis — Thu, 08 Nov 2007 10:35:39 +0000

Graham,

Thanks for the taking the time to comment – especially since you must be very busy getting ready for OpenWorld at the moment.

I can’t do anything at the moment to confirm that your observation is the solution to the puzzle, but I will be back on the client site in a couple of weeks and will check to see if I can find the balancing CPU in a later snapshot.

Ideally, of course, if there had been a single call (or small set of calls) responsible for the difference I would have seen something reported with zero exexutions in the “SQL ordered by CPU” section of the AWR report, with no matching report in any of the equivalent sections of the spreport.

Unfortunately, my AWR report doesn’t show any expensive code with zero executions; and Statspack has been configured with some very large thresholds, so there is virtually nothing in any of the SQL listings – which means I can’t sensibly compare the two to check for samples of SQL (or PL/SQL ) with small differences in execution counts but large differences in resource consumption.

To be continued….

By: Graham Wood

Graham Wood — Wed, 07 Nov 2007 22:46:25 +0000

I believe that the issue here is that the data reported as CPU time in 10g comes from DB CPU value in v$sys_time_model as opposed to the ‘CPU used by this session’ value in v$sysstat. There is a major difference between these two values, which is that sysstat value is only updated at the end of the call, whereas the v$sys_time_model value is updated every 5 seconds.
In a situation where there are calls that span snapshots this can lead to gross under/over accounting of the sysstat value, for example a call that takes around 3 hours to complete will appear as zero CPU usage for the first two hours, followed by 3 hours of CPU usage in the last hour.

By: Vlad Sadilovskiy

Vlad Sadilovskiy — Mon, 05 Nov 2007 21:09:15 +0000

Thanks, Jonathan. I also did my share of testing, but was not able to reproduce the issue you posted.

It is definitely strange to see this big gap. The possibilities of testing scenarios could be endless. For instance is possible that v$sys_time_model and v$sysstat hold information from different or intersecting sources as I mentioned in “recursive calls” post. Or, perhaps some rare tools or access methods or patterns do not register CPU utilization in the v$sysstat.

I wonder if this can be clarified with OS metrics captured by OS tools not from within the Oracle.

Whatever was included in the CPU time/DB CPU (from sys time model) by AWR, it will be very interesting to discover.

By: Recursive Calls « Observing Oracle

Recursive Calls « Observing Oracle — Mon, 05 Nov 2007 05:26:47 +0000

[...] figures of the later when reporting Top 5 Timed Events. This perhaps holds an explanation for the AWR oddity seen by Jonathan Lewis. It would be interesting to find the relevant clues in the reports or that [...]

By: Jonathan Lewis

Jonathan Lewis — Fri, 02 Nov 2007 10:08:18 +0000

Vlad,
Thanks for the note. The claim in the blog is almost certainly wrong, and I’ve just written in to the Oracle-L list to recant on this one; but there are still a couple of follow-up questions I’m going to have about the implications – so I’ll be leaving the blog in place and commenting on it in a few days.

DB CPU: The statspack figure is 3,210.5 (i.e. the total CPU (approx) as seen also by AWR).

The discrepancy between Statspack and AWR is probably explained (plus or minus a bit) in the OS Statistics from AWR:
SYS_TIME __________ 8,305 USER_TIME _________ 175,722 OS_CPU_WAIT_TIME __ 172,000

I assume you mean this from the reference manuals for the recursive CPU: “Total CPU time used by non-user calls (recursive calls). Subtract this value from “CPU used by this session” to determine how much CPU time was used by the user
calls.

Bear in mind that the manuals often get out of date, and aren’t always exact and unambiguous at the best of times. I suspect that that definition hasn’t changed since 5.1 – and explains why lots of people were still trying to “reduce the recursive CPU” 10 years after pl/sql blocks came on the scene.

“non-user” in this context means the CPU due to the function calls not made directly by the user. The statistic is, after all, only interested in CPU attributed to the Oracle process – it doesn’t know (or care) what is at the client end to the two-task.

By: Vlad Sadilovskiy

Vlad Sadilovskiy — Thu, 01 Nov 2007 23:20:54 +0000

Do you have DB CPU value for these cases?

I’d cross-verify this info using trace.

Description of the recursive CPU usage doesn’t seem to have changed for awhile.

On the side note, the “non-user” in the definition seems a little strange, as all calls non-user (as in “automatic”) and could be user made (as in “non-Oracle, 3rd party”) at the same time.