Re: session wait fun

From: John D Parker <orclwzrd_at_yahoo.com>
Date: Tue, 7 Jan 2014 11:33:15 -0800 (PST)
Message-ID: <1389123195.31249.YahooMailNeo_at_web163106.mail.bf1.yahoo.com>


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
>
>
>
>
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jan 07 2014 - 20:33:15 CET

Original text of this message