I think it’s impossible to say – and detailed interpretation may depend on Version and Platform.

I would assume that Oracle used a rounding mechanism to convert whatever time it acuired for CPU, so that the boundary case would be 5,000 ms rather than 10,000, and we might hope that on average the errors summed to zero across all sessions. We might also question whether Oracle populated the session value for “CPU Used by this session” by accumulating figures like “how many hundredths of CPU seconds have I used since last time” or whether it echoed the o/s result for “CPU time current recorded against this process”. The former would tend to introduce a cumulative error that might explain your results.

A couple of reference points:

a) you could query v$sess_time_model and compare it with v$sesstat to see if there were particular sessions that showed the largest discrepancy. This might give you some further ideas on the cause.

b) when I ran your query on the next 11.2.0.3 I used, the error was the other way – i.e. DB CPU was smaller (by about 5%) than CPU used. (I also had a few sessions which recorded CPU used, but showed zero DB CPU.

If I’m right, “CPU used by this session” is measured in tens of milliseconds and user calls under ten milliseconds are not added to this metric whereas “DB CPU” is measured in microseconds.

Could that difference in accuracy explain why “DB CPU” could be significantly higher than “CPU used by this session” ?
Would that mean that a lot of user calls complete in less than 10 millisecond in the following example ?

SQL> select cpu1, cpu2, cpu2 - cpu1
  2  from (
  3    select round(value / 10000) cpu2
  4    from   v$sys_time_model
  5    where  stat_name = 'DB CPU'),
  6       (
  7    select value cpu1
  8    from   v$sysstat
  9    where name = 'CPU used by this session');

      CPU1       CPU2  CPU2-CPU1
---------- ---------- ----------
   4591465    5878762    1287297

Thank you for your help

Sorry about the long delay in replying.

Your calculations look correct. However, to follow up the 70% question, I would also at the section on OS Statistics to cross-check the BUSY_TIME, and the split between SYS_TIME and USER_TIME – I like to ensure that different sources of information give consistent values before I jump to any conclusions.

I think you’re right! I’m going to investigate further on that!
The explanation was simple then… A monitoring script was disabled and a lot of the CPU it was using got free, so now the instance is more idle than before.

Thanks so much for your help!

I’ve had a quick look at an early and a late report. First thought 100 CPU seconds in one hour is virtually idle anyway.

But looking at where that CPU time came from (I checked SQL ordered by buffer gets as a first cross-check) most of it is coming from a couple of queries that look like monitoring queries (queries against v$lock and v$session, v$sql) and don’t look like application code.

These disappear from the later statspack. So maybe the person who was checking on the database decided it wasn’t worth the effort.

If you check the times you mention, the average wait time for each of those events hasn’t changed – it’s just that the reduction in CPU usage pushes their total time higher up the list and makes their percentage contribution higher.

Jonathan, I’ve just sent you an e-mail with Statspack reports so you can check them out.

Could a decrease like that in the “CPU used by this session” statistic mean that the database is not being used?

I can imagine a lot of people reading your note and thinking: “How can a drop from 90% to 60% be the same as dropping to one tenth of what it used to be”. I think I can guess what you’re looking at when you say this – but it’s not obvious. I can also guess why this might happen – but it’s not compatible with no change in the workload, application, or statspack output.

If you want to email me a pair of one-hour reports from before and after the change that you think are good examples of the difference, I’ll take a quick look at them – and write a note about them if they demonstrate a useful principle.