Re: session wait fun
- From: John D Parker <orclwzrd@xxxxxxxxx>
- To: "oratune@xxxxxxxxx" <oratune@xxxxxxxxx>, oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 7 Jan 2014 10:39:33 -0800 (PST)
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:
