Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Important: Oracle processes taking lots of CPU

Re: Important: Oracle processes taking lots of CPU

From: Stephane Faroult <>
Date: Tue, 23 Nov 2004 15:01:29 +0100
Message-Id: <>

 I know that it may seem confusing on oracle-l, but 'select' doesn't ONLY refer to the SQL language - in that case, it has to do with I/O multiplexing - try 'man select'. Identifying what your file descriptors are pointing to might help. In any case, you are more likely to see things with sar or iostatthat the V$ views, as you pointed. Regards,

Stephane Faroult

RoughSea Ltd

On Tue, 23 Nov 2004 05:25 , New DBA <> sent:


Yes if Oracle is not waiting but working no wait will be registered. But it should atleast be reflected in "CPU used by this session" stat. It doesn't.

I traced a few processes, but the trace files show no SQL which takes lots of CPU. Moreover, the CPU utlization in the trace file, or in v$sesstat don't match with the actual CPU taken by the process as seen from the OS commands like "top"

Thats why I believe its some kind of O/S issue.

So I did a truss on the process. And I saw the following line repeating infinitely.

select(2048, 0x800003fffdffb3d0, 0x800003fffdffb4d0, 0x800003fffdffb5d0, 0x800003fffdffb6d0) = 0

I'm not sure how to interpret the output of truss, so I posted it in this forum since there are many experts out here, who might be able to interpret it!

Is there any further information I can gather at the O/S level which throws some light on the problem?

As far as statspack is concerned, we haven't implemented statspack, but I did run utlbstat/utlestat and uploaded the output to It didn't suggested or detect excess CPU/LIOs, since those stats are pretty acceptable in the trace files.


>I'm no expert here, but here *may be* a few things
>to think about:
>When Oracle is actually doing something it isn't
>recorded as a wait event,
>e.g. getting a datablock that is in cache doesn't
>generate a wait event.
>If your query is "horrible" you could be using loads
>of CPU without
>generating many waitevents.
>A little more dodgy info: "db file sequential
>read" is normally
>accociated with datafile access by rowid, ie. after
>an index lookup.
>I think I'd try to find out which queries are
>running during the
>performance problem times and explaining the
>Also, have you run spreport for this time period?
>Told you I wasn't an expert, but I hope that prompts
>other readers to fill
>in the gaps and give you better hints,
>Good luck

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around[2]

--- Links ---
   1 javascript:parent.opencompose('','','','')
   2 modules/
   3 modules/
Received on Tue Nov 23 2004 - 08:03:30 CST

Original text of this message