Re: session wait fun
From: John D Parker <orclwzrd_at_yahoo.com>
Date: Mon, 20 Jan 2014 09:55:59 -0800 (PST)
Message-ID: <1390240559.41253.YahooMailNeo_at_web163101.mail.bf1.yahoo.com>
Here's what I have been able to determine. The epoch wait time is indeed bogus. I did run strace -T -ttt on both lgwr and vktm. Those traces look "normal" to me. I don't see any elapsed times that are screwy. What I believe is happening based on reading the comments on this thread is the following. the "SGA Time" is not getting updated properly in my 11.2.0.3 RAC environment due to some kind of slowdown in the backend storage that plugs ups the work and delays the updating of that time. The queries against v$session are yielding only the KSLWTSTIME value instead of the calculated delta because the "SGA Time" is incorrect or invalid. This in return yields the Epoch wait duration. Assuming that all my "supposes" and "assumptions" are correct this would be a bug. The upside is that I have a team mate seeing similar but not exactly the same behavior on an Exadata system. Their bad wait times can be traced back to slowdowns in processing parallel query jobs.
Date: Mon, 20 Jan 2014 09:55:59 -0800 (PST)
Message-ID: <1390240559.41253.YahooMailNeo_at_web163101.mail.bf1.yahoo.com>
Here's what I have been able to determine. The epoch wait time is indeed bogus. I did run strace -T -ttt on both lgwr and vktm. Those traces look "normal" to me. I don't see any elapsed times that are screwy. What I believe is happening based on reading the comments on this thread is the following. the "SGA Time" is not getting updated properly in my 11.2.0.3 RAC environment due to some kind of slowdown in the backend storage that plugs ups the work and delays the updating of that time. The queries against v$session are yielding only the KSLWTSTIME value instead of the calculated delta because the "SGA Time" is incorrect or invalid. This in return yields the Epoch wait duration. Assuming that all my "supposes" and "assumptions" are correct this would be a bug. The upside is that I have a team mate seeing similar but not exactly the same behavior on an Exadata system. Their bad wait times can be traced back to slowdowns in processing parallel query jobs.
Me thinks that the diff slowdowns are plugging up the same internal oracle pipe and thus preventing the "SGA Time" from getting updated properly. Patching is not likely to happen anytime soon so I'm trying to think up a work around. They are also not likely to fix the cause of the backend slowdown I perceive because they don't see it in their tiny lens. whew! I'm open to suggestions. John ________________________________ From: Jared Still <jkstill_at_gmail.com> To: John D Parker <orclwzrd_at_yahoo.com> Cc: oracle-l <oracle-l_at_freelists.org> Sent: Saturday, January 18, 2014 6:51 PM Subject: Re: session wait fun Just wondering if you had an opportunity to trace a session. It would be interesting to find know what the problem turned out to be. Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist Sr Oracle DBA at Pythian Pythian Blog http://www.pythian.com/blog/author/still/ Oracle Blog: http://jkstill.blogspot.com Home Page: http://jaredstill.com
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Jan 20 2014 - 18:55:59 CET