Re: session wait fun
- From: John D Parker <orclwzrd@xxxxxxxxx>
- To: David Fitzjarrell <oratune@xxxxxxxxx>, oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 7 Jan 2014 13:59:43 -0800 (PST)
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@xxxxxxxxx>
To: "orclwzrd@xxxxxxxxx" <orclwzrd@xxxxxxxxx>; oracle-l
<oracle-l@xxxxxxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxx>
To: orclwzrd@xxxxxxxxx
Cc: David Fitzjarrell <oratune@xxxxxxxxx>; ORACLE-L <oracle-l@xxxxxxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxx>
>To: "orclwzrd@xxxxxxxxx" <orclwzrd@xxxxxxxxx>; oracle-l
><oracle-l@xxxxxxxxxxxxx>
>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@xxxxxxxxx> 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
>
>
>
>
Other related posts:
