Is there any way to keep Oracle SQL Developer from closing my DB connections, or to increase the timeout? Sometimes during a long-running query SQL Dev will just close the conne
This doesn't sound like an issue with SQL developer, cetainly I've never come across it. Are you sure it's not something else, like your network? What happens if you connect from SQL plus from your desktop.
Also sounds like a firewall problem to me.
You may have some luck with setting EXPIRE_TIME parameter in the server's SQLNET.ORA file. From the documentation:
Use parameter SQLNET.EXPIRE_TIME to specify a the time interval, in minutes, to send a probe to verify that client/server connections are active. Setting a value greater than 0 ensures that connections are not left open indefinitely, due to an abnormal client termination. If the probe finds a terminated connection, or a connection that is no longer in use, it returns an error, causing the server process to exit. This parameter is primarily intended for the database server, which typically handles multiple connections at any one time.
10g Documentation on EXPIRE_TIME
Use SQLNET.EXPIRE_TIME at server side to request keep alive packets
See also: https://rammpeter.blogspot.com/2017/06/common-pitfalls-using-sqlnet-via.html
our DBA seems to have found a solution to this:
2.2. If there is a firewall present between the OC4J instance & the Database The firewall might drop inactive jdbc connections to the database server. However, the OC4J instance cannot detect that the firewall has timed out the connection to the database. Oracle Net can be configured with Dead Connection Detection (SQLNET.EXPIRE_TIME) to workaround this problem. Set EXPIRE_TIME on the database server to a value less than the firewall connection timeout so that DCD keeps the connection to the database alive. See Note 151972.1 "Dead Connection Detection (DCD) Explained". Since this is a setting configured on the database server, not on the midtier, it will apply for all database connections (OCI and thin JDBC). Alternative solutions: - Disable or increase the idle timeout parameter of the firewall. or - Configure the TCP Keepalive time setting on the database and on midtier servers to a value less than the firewall connection timeout. After setting the TCP Keepalive time, the machines will send repeatedly a null packet after the minutes specified to keep the connections alive. As the packet is sent every time inside the firewall idle timeout, the connection will not get closed.
#1. Check with th3 DBA what is the user's profile of the used connecting. Then check inactivity timeouts for the profile.
#2. Change the connection setting in SQL Developer to Connection Type=Basic and use SID (not Service Name).
If you use Connection Type=TNSNAMES or Service Name instead of SID - the connections will be dropped.
It's most likely a firewall between SQL Developer and the database that breaks things. You can solve that from SQL Developer using the SQL Developer Keepalive plugin.
You can also fix this from the Database Server by using the answers by Thomas and David Mann.
Oracle Net can be configured with Dead Connection Detection (SQLNET.EXPIRE_TIME) to workaround this problem. Set EXPIRE_TIME on the database server to a value less than the firewall connection timeout so that DCD keeps the connection to the database alive. See Note 151972.1 "Dead Connection Detection (DCD) Explained"
I don't have the answer for this, but I'm experiencing the same problem.
The firewall between my SQL Developer and the database automaticly closes "inactive" sessions. A long running query is according to the firewall an inactive session, so he closes it. I've not, yet, found how to make SQL Developer send packets over a connection with a long running query, so that the firewall doesn't close the connection. And I don't know if this is possible at all.
So I don't think it is a SQL Developer problem, but a firewall issue.
-- UPDATE
There is an extension for SQL Developer that allows you to keep the connections active: http://sites.google.com/site/keepaliveext/
It's not totally finished yet (for example the notification you get states the same timeout no matter what timeout you have specified) but it does the trick. I've not, yet, tested it against the latest SQL Developer pre-release, but it worked with SQL Developer 2.2.x
-- UPDATE
For SQL Developer 4+ you can use: http://scristalli.github.io/SQL-Developer-4-keepalive/