RE: New behavior in 11g?

  • From: Mohammad Rafiq <rafiq9857@xxxxxxxxxxx>
  • To: "cichomitiko@xxxxxxxxx" <cichomitiko@xxxxxxxxx>
  • Date: Mon, 2 Dec 2013 20:51:10 -0500

Thanks Dimitre.  Even after setting DCD parameter, it still time out so O was 
curious. 
 
Date: Sat, 30 Nov 2013 09:53:16 +0100
Subject: Re: New behavior in 11g?
From: cichomitiko@xxxxxxxxx
To: rafiq9857@xxxxxxxxxxx
CC: dramirezr@xxxxxxxxx; maureen.english@xxxxxxxxxx; phil@xxxxxxxxxx; 
oracle-l@xxxxxxxxxxxxx

Sorry for the previous incomplete email ...
Some firewalls implement idle timeout for security reasons. If such mechanism
 is active, when connection remains idle for a predefined period (usually set 
to 1h by default), the firewall resets the connection, the peers may or may not 
be notified.
By implementing DCD (sqlnet.expire_time), you  can avoid that connections get 
idle when they are still in use.



Regards
Dimitre


On Sat, Nov 30, 2013 at 4:15 AM, Mohammad Rafiq <rafiq9857@xxxxxxxxxxx> wrote:




How to reset 
 
and to reset the firewall idle timeout :)  ????
 
Thanks
 
Rafiq


 
Date: Fri, 29 Nov 2013 10:50:17 -0600
Subject: Re: New behavior in 11g?

From: dramirezr@xxxxxxxxx
To: maureen.english@xxxxxxxxxx
CC: phil@xxxxxxxxxx; oracle-l@xxxxxxxxxxxxx


Mmm interesting, I don't have that parameter defined, let me test it first.
Thanks!
RegardsDavid Ramírez Reyes


Profesión: Padre de Familia




On 29 November 2013 10:38, Maureen English <maureen.english@xxxxxxxxxx> wrote:


David,
The problem appears to be that we missed adding a parameter to our sqlnet.ora 
file on the newserver.  
We set sqlnet.expire_time=10


so that the database will check every 10 minutes to make sure that the process 
on the application server is still alive.
- Maureen



On Fri, Nov 29, 2013 at 5:23 AM, David Ramírez Reyes <dramirezr@xxxxxxxxx> 
wrote:



Interesting problem, am having the same (with less impact) on our db migrated 
to 11g (we were on 8i, -don't ask why-).
Please let me know if you find something on that side.




RegardsDavid Ramírez Reyes
Profesión: Padre de Familia







On 28 November 2013 16:37, Maureen English <maureen.english@xxxxxxxxxx> wrote:




Phillip,
Yes, there definitely is a firewall between the app server and the database 
server.  I thought it wasthe same firewall as is between the app server and the 
old database server, but that may not be 




true.  Or, the rules may not be the same...or....
I didn't think of this as possibly being a firewall issue, but now that you 
mention it, we also use IP tables on the new database server.  Even though we 
did the same on the old database server, 




this one could easily be set up differently.
Thanks!  Now I have another direction I can go for troubleshooting this problem.

- Maureen


On Thu, Nov 28, 2013 at 10:32 AM, Phillip Jones <phil@xxxxxxxxxx> wrote:





Hi,
'LOGOFF BY CLEANUP'  occurs when a session hasn't explicitly closed the 
connection & Oracle has to clean the session up itself.

Sounds like your new server is behind a firewall that drops connections after 2 
hours, causing the above. Talk to your network admins and ask what network 
hardware is between the app and database server.






Thanks,
Phil


On Thu, Nov 28, 2013 at 7:19 PM, Maureen English <maureen.english@xxxxxxxxxx> 
wrote:






We have an application that has been using a 10g database for years.  We just




created a new 11.2.0.4 RAC database on a new RHEL5 Linux server.  
 The audit trail, however, shows the last 

entry for that user as doing a 'LOGOFF BY CLEANUP'.  I'm 95% sure that there 
hadbeen no communication between the application and the database for this user 
for the 2 hours before it disappeared...I was monitoring netstat output and the 
audit trail.







I'm also sure that this is related to either some kind of timeout on the new 
database server, or some kind of timeout in the database.  IDLE_TIME for the 
profile is set to UNLIMITED, so it's not that.  No alert log info and no trace 
file info to show anything






is wrong.   
It really looks like something is killing the Oracle process, but I don't know 
where else to look.  Is there some kind of system parameter that may have been 
set that






kills processes that are essentially inactive?
- Maureen










                                          

                                          

Other related posts: