Re: SCAN addresses and TNSNames

  • From: Adric Norris <landstander668@xxxxxxxxx>
  • To: wbeldma@xxxxxx
  • Date: Wed, 2 Oct 2019 15:23:26 -0500

What version of the Oracle client is being used? IIRC the 11.2.0.4 client
only attempts the first IP returned by DNS, so while impacted IPs are in
the process of being relocated you can definitely get unlucky. 12c+ clients
should recognize that there are multiple IPs, and try each of them before
giving up.

On Wed, Oct 2, 2019 at 12:51 PM William Beldman <wbeldma@xxxxxx> wrote:

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?



-- 
"In the beginning the Universe was created. This has made a lot of people
very angry and been widely regarded as a bad move." -Douglas Adams

Other related posts: