Re: session wait fun

Can you trace a session as well and see if the wait times reported there are also crazy. I'd then be using that as a test case for Oracle support. At the risk of insulting your intelligence you have double checked that your query for wait times makes sense.. BTW did my maths on the train last night make sense? I.e does the implied start of wait correspond to Jan 1st 1970?

On Tue, Jan 7, 2014 at 9:59 PM, John D Parker <orclwzrd_at_yahoo.com> wrote:

> Well, cluvfy comp clocksync -n all -verbose indicates that all is will
> with NTP. there are loads of crs-2409 messages and octssd.log has loads of
> off by xxx usec messages. But we seem to be close as far as I can tell for
> time.
> What's goofy is this started about mid december.
>
> john
>
> ------------------------------
> *From:* David Fitzjarrell <oratune_at_yahoo.com>
> *To:* "orclwzrd_at_yahoo.com" <orclwzrd_at_yahoo.com>; oracle-l <
> oracle-l_at_freelists.org>
> *Sent:* Tuesday, January 7, 2014 1:42 PM
>
> *Subject:* Re: session wait fun
>
> We, at one point, lost contact with an NTP time server (lost contact with
> the location) and all sorts of strange behavior surfaced, including node
> evictions. You may have contact with the NTP source but it may be having
> issues, as Niall mentioned. I didn't even get that far in the thought
> process on this issue, expecting it to be a Linux release issue.
>
> Thanks, Niall.
>
>
> David Fitzjarrell
>
>
>
> On Tuesday, January 7, 2014 12:33 PM, John D Parker <orclwzrd_at_yahoo.com>
> wrote:
> ok, here's a bit more I have 2 rac nodes in prod and 2 in stage and they
> are all exhibiting this behavior variously. I'm wondering what's connected
> on the backend that's causing this. timesource.. interesting.. headed off
> to dig some more.
>
> john
>
> ------------------------------
> *From:* Niall Litchfield <niall.litchfield_at_gmail.com>
> *To:* orclwzrd_at_yahoo.com
> *Cc:* David Fitzjarrell <oratune_at_yahoo.com>; ORACLE-L <
> oracle-l_at_freelists.org>
> *Sent:* Tuesday, January 7, 2014 1:23 PM
> *Subject:* Re: session wait fun
>
> Your wait times sound suspiciously close to time since Unix Epoch. I
> wonder if you might have a dead/unreachable timesource somewhere.
> On Jan 7, 2014 6:41 PM, "John D Parker" <orclwzrd_at_yahoo.com> wrote:
>
> Red Hat Enterprise Linux Server release 5.8 (Tikanga)
> uname -a says 64 bit.
>
> So since I cast a wide net, how about just the time overflow issue to 44
> years.
>
> I hesitate to run strace on this particular production environment.
>
> john
>
> ------------------------------
> *From:* David Fitzjarrell <oratune_at_yahoo.com>
> *To:* "orclwzrd_at_yahoo.com" <orclwzrd_at_yahoo.com>; oracle-l <
> oracle-l_at_freelists.org>
> *Sent:* Tuesday, January 7, 2014 12:23 PM
> *Subject:* Re: session wait fun
>
> Dear Frustrated,
>
> What is the release of Linux you are using, and is it 32-bit or 64-bit?
> Does strace on the suspect process show anything unusual? (I do understand
> that strace generates a LOT of output so it might be desirable to tee that
> to a file and check it for possible issues).
>
> Without the above information it's difficult to 'get a read' on this and
> provide any useful insight.
>
>
> David Fitzjarrell
>
>
>
> On Tuesday, January 7, 2014 10:54 AM, John D Parker <orclwzrd_at_yahoo.com>
> wrote:
> On 11.2.0.3 on linux, I'm getting session waits of 16070 days. This
> equates to 44 years in my math. This smells like the old overflow issue
> that I remember from days of old. My google fu is not working to find
> anything related to excessive, impossible, unreasonable, overflow session
> wait times. Anyone have some info? or a bug number? This is making me
> crazy. The other thing is that it seems to be some how related to slow redo
> log performance in the log writer. But I'm seeing non idle sql net message
> for client waits and other events at 16000+ days of wait, doesn't matter
> which column in v$session I look at that math comes back the same. truly
> bizarre.
>
> Frustrated,
> john
>
>
>
>
>
>
>
>
>
>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

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