Problem: ORA-12545 and connection pooling in ODP.NET

Problem: ORA-12545 and connection pooling in ODP.NET


We have an ASP.NET application (C# .Net 1.1) which connects to Oracle 10g RAC using Oracle data provider for .Net (v 10.1). It appear that on quite reqular interval (sometimes every 60 minutes) connection get lost and 12545 errors appear in our logs. We use connection pooling so sometimes only some of our connections die while others are still performing OK. I am not 100% convinced that underlying network is not the cause for the timeout problem as sometimes connections get lost between IIS and the clients.
I have 2 questions:
– Is it some known issue and is there a workaround for this situation?
– Is there any way to force specific connection (failed one) out of the connection pool and create new one (may be in some kind of loop so we can wait for connection to restore)?

Thank you.


Solution: ORA-12545 and connection pooling in ODP.NET

If the protocol is TCP/IP, edit the TNSNAMES.ORA file to change the  host name to a numeric IP address and try again.

In a multiple node RAC environment listeners do the load balancing between  all the  instances. So after receiving a connection request from the client,  listener may send a redirect packet to the client to redirect it to the listener of another node. ORA-12545 error will be reported in the client if client is unable resolve the host name mentioned in the redirect packet.

For example, suppose the client can only resolve hostname if it is in the format of  hostname.domianname like Now if in the redirect packet listener send “host=abcd”, client will not be able to resolve this and will report ORA-12545.

Please ensure that local_listener and remote_listener parameters are set correctly. Not lets
assume that the


and in tnsnames.ora

Please ensure that here you set HOST=hostname.domianname.


So the rule is you should set the host field of the local_listener to a name which can be resolved by the clients in your environment.

Please ensure the same thing with the remote_listener parameter also.