Re: CPU time missing from 10046 trace of cached table

On Jul 20, 9:28 am, bdurrettc..._at_yahoo.com wrote:
> On Jul 19, 4:25 pm, sybra..._at_hccnet.nl wrote:
>
>
>
>
>
> > On Thu, 19 Jul 2007 11:56:59 -0700, bdurrettc..._at_yahoo.com wrote:
> > >Looks like 10046 traces don't correctly report the CPU usage of full
> > >scans of cached tables.
>
> > I don't see a 10046 trace, ie RAW data, so what is your issue?
> > You didn't post this for a second time because my response didn't suit
> > you, did you?
> > You don't provide any details: not on how busy the database is, not
> > how busy the server is, you just complain that the wall clock ticks
> > faster than the CPU!
> > What a big surprise.
> > Come up with *evidence* instead of unfounded 'claims' and 'myths'.
>
> > --
> > Sybrand Bakker
> > Senior Oracle DBA
>
> I don't know what's going on with Google Groups. I still can't find
> my first post or your reply. Sorry I missed it.
>
> To answer your question, the system was idle. If the CPU was pegged
> then the difference between elasped time and CPU time could be
> explained by CPU queue time. But it wasn't.
>
> I was really puzzled by this result. Hard to understand how the CPU
> time could be this far off. If you have a better explanation that
> would be great.
>
> Here is a zip of the sql, trace file, tkprof output, etc. if you want
> to see the details:
>
> http://www.geocities.com/bobbyandmarielle/simplecached.zip
>
> - Bobby- Hide quoted text -
>
> - Show quoted text -

Ack! Never mind. It appears that my system is busier than I thought.

10:00:31     cpu runq-sz %runocc swpq-sz %swpocc
10:01:31       0     2.4      58
               1     3.4     100
          system     3.0      79     0.0       0

It looks like it was just queue time that made the difference. Sorry for the confusion. Thanks for your reply.

• Bobby