RE: Dead Connect detect
- From: "Goulet, Richard" <Richard.Goulet@xxxxxxxxxxx>
- To: "Jorgensen, Finn" <Finn.Jorgensen@xxxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 4 Apr 2011 11:20:44 -0400
OK, I've two questions:
1) I'm using Redhat Linux
2) I don't want the firewall settings to be exceeded so sending a
packet just to keep the connection open is not desired. What is is to
find those that are dead & clean up on the Oracle side.
Dick Goulet
Senior Oracle DBA/NA Team Leader
________________________________
From: Jorgensen, Finn [mailto:Finn.Jorgensen@xxxxxxxxxxxxxxxxx]
Sent: Monday, April 04, 2011 10:07 AM
To: Goulet, Richard; 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: Dead Connect detect
Dick,
Gwen Shapira did a presentation at Hotsos 2011 that involved this type
of scenario. 2 of the proposed solutions were as follows (copy and paste
from her presentation) :
Another solution will be to modify kernel parameter
net.ipv4.tcp_keepalive_time
to a value lower than the firewall timeout values. This should give the
TCP
keepalive a chance to keep the connection alive.
A third solution can be to use SQLNET keep-alive parameter
SQLNET.EXPIRE_TIME that allows Oracle to send its own keep-alive probes
from the server to the client, normally sent every 10 minutes. These
probes will
also keep the connection a live and not allow the firewall to disconnect
it.
Thanks,
Finn
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Goulet, Richard
Sent: Monday, April 04, 2011 9:52 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Dead Connect detect
All,
Many years ago (version 9.2) I toyed with this capability of
SQL*Net without much luck. Has anyone toyed with it in recent times
(11.1.0.7) with much success??? I'm facing an issue where we have web
servers in a DMZ that connect back to the database and the firewall has
a 24 hour idle timeout, so I end up having to manually disconnect some
sessions every day.
Dick Goulet
Senior Oracle DBA/NA Team Leader
>>> This e-mail and any attachments are confidential, may contain legal,
professional or other privileged information, and are intended solely
for the addressee. If you are not the intended recipient, do not use
the information in this e-mail in any way, delete this e-mail and notify
the sender. CEG-IP1
Other related posts:
