Re: seconds_in_wait

I think you'd also want to pay attention to the STATE column in your query * If it's "WAITING" - only then the waiting is ongoing * If it's "WAITED % TIME" - the waiting has completed and the wait_class and event contains the information about the previous wait event. Also seconds_in_wait
will display time since the wait completed. (These sessions may be inactive or on CPU)

I don't have any idea why you'd see the large values in seconds_in_wait for the LGWR case you described.

---
Maris Elsins
_at_MarisElsins <https://twitter.com/MarisElsins>
www.facebook.com/maris.elsins



On Mon, Sep 21, 2015 at 3:44 PM, Jay Hostetter <hostetter.jay_at_gmail.com>
wrote:



> (reposting with the correct email address )

>

> I have a query that monitors for sessions that are "stuck" on non-idle

> wait events.

>

> select username, sid, event, seconds_in_wait

>  from gv$session

> where wait_class != 'Idle'

>    and seconds_in_wait > 300

>

> I've discovered that over time, this query will catch the the LGWR session

> with a seconds_in_wait value that is extremely high for "log file parallel

> write" (e.g.1442837632).  There is no way that the log writer is waiting

> this long.  I've been trying to search for any known bugs related to wait

> events.  I just wanted to check with the list to see if anyone has ever run

> into this issue or has any insight.  The query seems to be fine, In this

> particular case, the database has been up for only 45 days.

>

> Oracle EE 11.2.0.3.15 on SUSE Linux 11.

>

> Thank you,

> Jay

>


--
http://www.freelists.org/webpage/oracle-l