Home -> Mailing Lists -> Oracle-L -> Re: SCAN addresses and TNSNames

Re: SCAN addresses and TNSNames

From: Leng <lkaing_at_gmail.com>
Date: Fri, 4 Oct 2019 07:26:40 +1000
Message-Id: <05547015-5086-4906-BE01-48A6F0EC8ACB_at_gmail.com> 








Hi Guys,



Have you got the relevant note/bug handy re. 11g clients not attempting all 3 scan listeners? We’ve got 11g clients and they couldn’t connect to our 2 node RaC databases during our rolling patching exercise.



Cheers,


Leng


> On 3 Oct 2019, at 6:31 am, William Beldman <wbeldma_at_uwo.ca> wrote:
> 
> 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


Received on Thu Oct 03 2019 - 23:26:40 CEST












Original text of this message