Re: SCAN addresses and TNSNames

Ah yes, good point. I read that before and I think it applies to any client <11.2.0.2

All clients that experienced the issue were 12.1 or 12.2 so that doesn't explain the problem.

-- 
Will Beldman
Database Analyst
Western Technology Services
Western University
p. 519-661-2111 x80357
e. wbeldma_at_westernu.ca
k. keys.uwo.ca (PGP key)

On Wednesday October 2 2019 03:23:26 PM Adric Norris wrote:


> 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_at_uwo.ca> 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?






--
http://www.freelists.org/webpage/oracle-l