SCAN addresses and TNSNames
Date: Wed, 2 Oct 2019 17:50:13 +0000
Message-ID: <142743723.pGaIt064jH_at_wbeldma>
I find the documentation on both SCAN addresses and TNSNames entries is good but is still missing some details.
I have a two node RAC cluster:
$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node <NODE 2> SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node <NODE 1> SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node <NODE 1>
My DNS resolves my SCAN address to 3 different IPs (and I can confirm DNS round-robin is working, the order is different everytime):
$ nslookup dm01-scan.<suffix>
Server: 127.0.1.1 Address: 127.0.1.1#53
Name: dm01-scan.<suffix>
Address: <IP 1>
Name: dm01-scan.<suffix>
Address: <IP 2>
Name: dm01-scan.<suffix>
Address: <IP 3>
My TNSNames entry is very basic:
(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dm01-scan.<suffix>)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = <service name>))
)
We had a crash on one of the nodes (at least it looks like only one) and some of my processes could not establish a connection to the database. If I was unlucky, I *think* this means 2 out of my 3 scan listeners was not working.
So I'd like to understand the behavior on the client side when that happens.
If so, would supplying retry and delay parameters mitigate this issue? More importantly, if I do not supply these parameters, what's the default behavior and where is that documented? What if it keeps returning a bad IP first?
Also, in the event of a sudden disconnect of an ALREADY established connection, is there any TNSNames parameters I can supply to ask the process to either "pause and wait for the database to come back" or "re-establish your connection to the same scan address again"? Could I perhaps use the "failover" parameter but have the failover address just be the same scan address?
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Oct 02 2019 - 19:50:13 CEST