Hi Jay,
So it looks like the wait time is not unreasonable for this session that is
calling dbms_lock.sleep.
And the time seems correct.
strace on vktm shows no gettimeofday calls
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.
Jay Hostetter <hostetter.jay@xxxxxxxxx> 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