Daniel, 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. -- Regards, Tanel Poder http://blog.tanelpoder.com <http://blog.tanelpoder.com/> _____ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Daniel Fink Sent: Thursday, August 07, 2008 02:38 To: kmoore@xxxxxxxxxxxx Cc: oracle-l 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. Regards, Daniel Fink -- Daniel Fink 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 OptimalDBA http://www.optimaldba.com Oracle Blog http://optimaldba.blogspot.com Lost Data? http://www.ora600.be/