Someone told me if I set the "ValidateConnection" property in Oracle to TRUE, the application will be able to handle the following cases:
Timeouts on network equipment that shutdown TCP connections after a certain
amount of time and/or inactivity.
Physical connection breaks such as pulled cables, network equipment resets,
etc.
Oracle server being restarted, or DBA logically closing the connection on
the server side.
My questions are:
If ValidateConnection is set to TRUE, can oracle actually handle the above cases?
Do I need to write additional code or Oracle's connection pool will just wait until the connection is timedout?
What technique or tools can I use to test this cases? Sample code, or link to other article will be very useful.
Thanks.
ValidateConnection simply tells Oracle to test the connection from the pool prior to handing it to the application. This prevents you from getting already disconnected connections from the connection pool. To answer your question of which situations are handled by using ValidateConnection, I guess I would need to know what you mean by "handle". If the Oracle server has been disconnected from the internet, ValidateConnection cannot do anything about it. However, once it is back online, ValidateConnection will prevent Oracle from handing your application disconnected connections from the connection pool. The link below gives some a little more information, and he shortly describes how he tested ValidateConnection in his environment.
http://spdeveloper.net/2009/10/disconnected-odp-net-and-system-data-oracleclient-connections/
Related
I'm using beanstalkd to offload some work to other machines. The setup is a bit unusual, the server is on the internet (public ip) but the consumers are behind adsl lines on some peoples homes. So there is a linux server as client going out through a dynamic ip and connecting to the server to get a job. It's all PHP and I'm using pheanstalk library.
Everything runs smoothly for some time, but then the adsl changes the IP (every 24h hours the provider forces a disconnect-reconnect) the client just hangs, never to go out of "reserve".
I thought that putting a timeout on the reserve would help it, but it didn't. As it seems, the client issues a command and blocks, it never checks the timeout. It just issues a reserve-with-timeout (instead of a simple reserve) and it is the servers responsibility to return a TIME_OUT as the timeout occurs. The problem is, the connection is broken (but the TCP/IP doesn't know about that yet until any of the sides try to talk to the other side) and if the client blocked reading, it will never return.
The library seems to have support for some kind of timeouts locally (for example when trying to connect to server), but it does not seem to contemplate this scenario.
How could I detect the stale connection and force a reconnect? Is there some kind of keepalive on the protocol (and on the pheanstalk itself)?
Thanks!
You could try to close each connection right after the request is answered and reopen a new connection each time.
There is no close() function but you deleting the Pheanstaly Object with unset($pheanstalk) will close it.
This explanation is quite helpful:
Pheanstalk (PHP client for beanstalk) - how do connections work?
I haven't tried it yet, but I came up with the idea of connecting to the beanstalk server through an SSH tunnel. We can enable the ServerAliveCountMax and ServerAliveInterval options on the tunnel, so that a network or server failure will cause the tunnel to close. This should then cause the pheanstalk client to report an error.
I am getting this error when I try to connect to my database:
ora-12528: TNS:Listener: All Appropriate instances are blocking new connections
I tried the following, with no success:
Stop and Start the Listener.
Shutdown and Startup database.
Restart the oracle services.
How might I resolve this?
You might have a problem with either the network and/or the archive logs - the above usually happens when the area/disk where the archive logs are stored is full, Oracle then just refuses new connections.
Another possibility is that you maxed out the number of allowed connections - this should usually be warning sign that you might have an application which leaks connections.
If you are 100% sure that you are not leaking connections then you could configure Oracle to accept more connections (BEWARE of licensing, RAM etc.!).
I have an oracle client which communicates with an Oracle database through a firewall.
I have been asked to limit the number of ports that need to be opened to an absolute minimum.
I think it should be possible to limit the firewall to open port 1521 only, if I also set the USE_SHARED_SOCKET = TRUE setting in the database server's registry.
Without the USE_SHARED_SOCKET setting, it seems that the Oracle SQLNET client is handed alternate server ports to use after the initial request to the listener on 1521.
This is an existing application, and I don't want to create havoc if - by setting this parameter - I break database communication in the application.
What - if any - adverse effects could I expect by using USE_SHARED_SOCKET = TRUE?. Is this a recommended firewall strategy? I've seen forums mentioning being locked to "dedicated server mode", but I don't think I understand if this is relevant.
Apparently Metalink NOTE 124140.1 provides some additional information, but I don't have access to Metalink.
On platforms and architectures that Oracle redirects connections to different ports (to the best of my knowledge, Windows servers in general and Unix servers for shared server connections), it generally does so for reasons of efficiency. If you set USE_SHARED_SOCKET to TRUE, you create the potential that there will be performance problems because the operating system has to deal with a lot of traffic for a lot of different logical connections on the same port.
Whether the potential performance problems actually affect your application, of course, is something that you'd have to test. The more connections you have, the more network traffic you create, the greater the potential for problems. But the vast majority of applications won't see any appreciable performance problems.
stupid problem. I get those from a client connecting to a server. Sadly, the setup is complicated making debugging complex - and we run out of options.
The environment:
*Client/Server system, both running on the same machine. The client is actually a service doing some database manipulation at specific times.
* The cnonection comes from C# going through OleDb to an EasySoft JDBC driver to a custom written JDBC server that then hosts logic in C++. Yeah, compelx - but the third party supplier decided to expose the extension mechanisms for their server through a JDBC interface. Not a lot can be done here ;)
The Symptom:
At (ir)regular intervals we get a "Address already in use: connect" told from the JDBC driver. They seem to come from one particular service we run.
Now, I did read all the stuff about port exhaustion. This is why we have a little tool running now that counts ports and their states every minute. Last time this happened, we had an astonishing 370 ports in use, with the count rising to about 900 AFTER the error. We aleady patched the registry (it is a windows machine) to allow more than the 5000 client ports standard, but even then, we are far far from that limit to start with.
Which is why I am asking here. Ayneone an ide what ELSE could cause this?
It is a Windows 2003 Server machine, 64 bit. The only other thing I can see that may cause it (but this functionality is supposedly disabled) is Symantec Endpoint Protection that is installed on the server - and being capable of actinc as a firewall, it could possibly intercept network traffic. I dont want to open a can of worms by pointing to Symantec prematurely (if pointing to Symantec can ever be seen as such). So, anyone an idea what else may be the cause?
Thanks
"Address already in use", aka WSAEADDRINUSE (10048), means that when the client socket prepared to connect to the server socket, it first tried to bind itself to a specific local IP/Port pair that was already in use by another socket, either an active one or one that has been closed but is still in the FD_WAIT state. This has nothing to do with the number of ports that are available.
I'm having the same issue on a Windows 2000 Server with a .Net application connecting to a SQL Server 7.0. There's like 10 servers with the same configuration and only one is showing this error several times a day. With a small test program I'm able to reproduce the error by just establishing a TCP connection on the SQL Server listening port. Running CurrPorts (http://www.nirsoft.net/utils/cports.html) shows there's still plenty of available ports in range 1024-5000.
I'm out of ideas and would like to know if you've found a solution since you've posted your question.
Edit : I finally found the solution : a worm was present on the server (WORM_DOWNAD.A) and exhausted local ports without being noticed.
I am working in an environment where we get production issues from time to time related to Oracle connections. We use ODP.NET from ASP.NET applications, and we suspect the firewall closes connections that have been in the connection pool too long.
Sometimes we get an "ORA-12571: TNS packet writer failure" error, and sometimes we get "ORA-03135: connection lost contact."
I was wondering if someone has run into this and/or has an understanding of the difference between the 2 errors.
Using a mobile phone analogy:
ORA-12571 (Failure) Means call is dropped.
ORA-03135 (Connection Lost) Other party hung up.
My understanding is that 3135 occurs when a connection is lost. This doesn't tell you why the connection was lost, though. It may have been terminated by the server because the server failed to recieve a response to a probe for a certain amount of time, and assumed that the connection was dead. Or (I'm not sure about this) the exact reverse of that: the client failed to recieve a probe response from the server for a certain amount of time, so it assumed the connection was lost. The "certain amount of time" is cotrolled by SQLNET.EXPIRE_TIME=[minutes] in sqlnet.ora.
As for 12571, my (again vague) understanding is that there was a sudden failure to send a packet during communication with the server, and that this is typically caused by some software or hardware interfering with the connection (either by design, or by error). For instance, if you pull out your ethernet cable and then try to execute a query, you'll probably get this. Or if a firewall or anti-malware application decides to block the traffic.