RE: 10046 trace - unaccounted for time
Date: Fri, 08 Aug 2008 18:45:54 +0800
A little addition...
Seconds_in_wait is just a delta between current SGA time (updated by LGWR) and the last session wait state change timestamp. So, seconds_in_wait should be interpreted rather as "seconds since last wait state change" and it increases even when session is constantly spinning on CPU. When session is not waiting and seconds_in_wait is increasing and "CPU used by this session" is not increasing, this can be either uninstrumented wait as you said or that the "CPU used by this session" is not just updated yet as this is done in the end of call only.
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Daniel Fink
Sent: Thursday, August 07, 2008 02:38
Subject: Re: 10046 trace - unaccounted for time
There is a 4th possible session state. It may be that the session is in an uninstrumented event. While this is unlikely, it does happen. I have seen this in active sessions where the event state is 'WAITED KNOWN TIME', the seconds_in_wait are increasing and the statistic 'CPU used by this session' is not increasing.
Check the FETCH entry that encompasses those WAITs. If the c value (cpu time) matches up with the 'missing' time, you were likely using a lot of CPU. If the cpu time does not match, you could be waiting on cpu or in an uninstrumented event.
Help me support The Children's Hospital of Denver!
I'm riding in the 2008 Courage Classic - 157 miles in 3 days
Help me reach my goal of $2,500.00 in donations.
Visit my Personal Rider Page http://www.couragetours.com/2008/danielwfink to donate
OptimalDBA.com - Oracle Performance, Diagnosis, Data Recovery and Training
Oracle Blog http://optimaldba.blogspot.com
Lost Data? http://www.ora600.be/
http://www.freelists.org/webpage/oracle-l Received on Fri Aug 08 2008 - 05:45:54 CDT