Re: SCAN addresses and TNSNames
From: William Beldman <wbeldma_at_uwo.ca>
Date: Thu, 3 Oct 2019 21:38:26 +0000
Message-ID: <2734150.GAsS2v10o1_at_wbeldma>
If you are using a client earlier than Oracle Database 11g Release 2, then you cannot fully benefit from the advantages of the SCAN because the Oracle Client cannot handle a set of three IP addresses returned by the DNS for the SCAN. Instead, it tries to connect to only the first address returned in the list and ignores the other two addresses. If the SCAN Listener listening on this specific IP address is not available or the IP address itself is not available, then the connection fails.
Date: Thu, 3 Oct 2019 21:38:26 +0000
Message-ID: <2734150.GAsS2v10o1_at_wbeldma>
If you are using a client earlier than Oracle Database 11g Release 2, then you cannot fully benefit from the advantages of the SCAN because the Oracle Client cannot handle a set of three IP addresses returned by the DNS for the SCAN. Instead, it tries to connect to only the first address returned in the list and ignores the other two addresses. If the SCAN Listener listening on this specific IP address is not available or the IP address itself is not available, then the connection fails.
I also discovered this limitation when we tried a rolling patch.
-- 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 Friday October 4 2019 07:26:40 AM Leng wrote:Received on Thu Oct 03 2019 - 23:38:26 CEST
> 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.
> >
> >> 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