Re: seconds_in_wait

>Do you mean that it shows 122 seconds, but you have waited much less?

I mean that I had waited around 122 seconds. If there was an issue with the SGA time or system time, I would expect the astronomical number I see for my log file parallel write wait event.

>If this is the current (correct) time and the query still returns the
wrong seconds_in_wait at this point in time then it may likely be caused by the stored start time of the wait event (which is also based on epoch time).

I agree. I believe it is this particular wait event.

>Are these two databases virtualized in some kind of way (e.g. VMware,
etc.)?

Yes, they are running on VMWare, on different guests.

Thank you,
Jay

On Tue, Sep 22, 2015 at 4:59 PM, Stefan Koehler <contact_at_soocs.de> wrote:

> Hi Jay,
>
> > So it looks like the wait time is not unreasonable for this session that
> is calling dbms_lock.sleep.
>
> Do you mean that it shows 122 seconds, but you have waited much less? It
> would be a reproducible test case and you could identify an issue with the
> epoch time stamp by tracing vktm before and while running this test case.
>
>
> > And the time seems correct.
>
> If this is the current (correct) time and the query still returns the
> wrong seconds_in_wait at this point in time then it may likely be caused by
> the
> stored start time of the wait event (which is also based on epoch time).
>
>
> > strace on vktm shows no gettimeofday calls
>
> This is caused by vDSO / vsyscall64. Please check out this article for
> more detailed information about it: https://lwn.net/Articles/446528/
> You can by-pass vDSO with the following procedure - afterwards you will
> see the syscall gettimeofday():
> shell> echo 0 > /proc/sys/kernel/vsyscall64
>
>
> > I have this issue in two databases. I bounced one, and now it is fine.
> I have not yet bounced the other, and my query continues to catch the
> > issue.
>
> Are these two databases virtualized in some kind of way (e.g. VMware,
> etc.)?
>
> Best Regards
> Stefan Koehler
>
> Freelance Oracle performance consultant and researcher
> Homepage: http://www.soocs.de
> Twitter: _at_OracleSK
>
> > Jay Hostetter <hostetter.jay_at_gmail.com> hat am 22. September 2015 um
> 19:18 geschrieben:
> >
> > Thank you for the responses. I have this issue in two databases. I
> bounced one, and now it is fine. I have not yet bounced the other, and my
> > query continues to catch the issue. Now for testing in this database,
> per Stefan's suggestion:
> >
> > SQL> run
> > 1 select s.indx, w.kslwtstime, w.kslwtltime,
> decode(w.kslwtinwait,0,round((w.kslwtstime+w.kslwtltime)/1000000),
> > 2 round(w.kslwtstime/1000000)) as SEC, e.kslednam
> > 3 from x$ksuse s, x$ksled e, x$kslwt w
> > 4* where bitand(s.ksspaflg,1)!=0 and bitand(s.ksuseflg,1)!=0 and
> s.indx=w.kslwtsid and w.kslwtevt=e.indx and s.indx =47
> >
> > INDX KSLWTSTIME KSLWTLTIME SEC KSLEDNAM
> > ---------- ---------- ---------- ----------
> ----------------------------------------------------------------
> > 47 121597780 0 122 PL/SQL lock timer
> >
> >
> > So it looks like the wait time is not unreasonable for this session
> that is calling dbms_lock.sleep.
> >
> > SQL> oradebug setmypid
> > oradebug dumpvar sga ksudbrmseccnt
> > ub4 ksudbrmseccnt_ [06000ABA0, 06000ABA4) = 56017B56
> >
> > in decimal: 1442937686
> > epoch time: 4:01:26 pm UTC Tuesday 9/22/15
> >
> > And the time seems correct.
> >
> > strace on vktm shows no gettimeofday calls.
> >
> > I'll continue to poke around.
> >
> > Thank you,
> > Jay
>

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