SCAN addresses and TNSNames

  • From: William Beldman <wbeldma@xxxxxx>
  • To: "'ORACLE-L (oracle-l@xxxxxxxxxxxxx)'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 2 Oct 2019 17:50:13 +0000

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.

What I suspect happened was when my client attempted to connect to the 
database, DNS returned a bad IP first, and my client connection failed and 
gave up. 

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?

Attachment: signature.asc
Description: This is a digitally signed message part.

Other related posts: