RE: 11.2 client and DNS

From: Wolfson Larry - lwolfs <>
Date: Thu, 24 May 2012 20:50:06 +0000
Message-ID: <>

Thanks Yong.
  This wasn't a RAC database, though we have plenty, but that was only doc I found at the time. One of our network guys said

"Network team doesn't do DNS. If it's OUR server, we may provide the OS and patching, etc, but I'm not sure who actually is responsible for the DNS entries specifically - some customers may have US doing it (possibly a windows team person if that's what controls the root of their DNS services), but other customers control their own DNS, and just have US keep the box running from the OS standpoint.

I _believe_ that client has someone on their side that is responsible for DNS in their case, but don't even know how to confirm that. If a DNS server went down and took a long time to get fixed, you might want to ask the correct order to try servers in for your resolv.conf file. As long as you're using the same servers in the same order, if there's a problem, EVERYONE will know it when it takes longer to resolve, and it should be noticed quicker and fixed. The issue is not if the server is dead, as it will fail and go to the next server after a delay, but if the box is up on the network, but not serving correct DNS info, or has a dead disk, and it's answering on port 53 for the service but can't actually look anything up (meaning it failed in a strange / non-typical way), then you can be waiting for it and wasting more time. Especially those services that are not reconfigured to avoid doing a reverse lookup on inbound connection attempt, you'll find all sorts of new delay  s and performance issues showing up that you'll have to track back to DNS before you rule everything out"

And there were 3 servers in the resolv.conf file. Just wondering if everyone was using 11.2 client problem would be less noticeable. Because it's smarter.


-----Original Message-----
From: Yong Huang [] Sent: Thursday, May 24, 2012 3:30 PM
To: Wolfson Larry - lwolfs
Subject: Re: 11.2 client and DNS


I think you're talking about several issues at the same time:

(1) A RAC SCAN is not resolved to 3 IP's. Verify with nslookup.

(2) `nslookup <SCAN>' on the client side multiple times does not rotate the IP's. Verify with nslookup.

(3) Pre-11gR2 Oracle client does not round-robin. See section "Problem with pre-11gR2 clients" at

(4) SCAN VIP and its SCAN listener are on different nodes of a RAC database.

The last issue is the most complicated and I was not able to reproduce. See,3
(ignore the issue of netstat showing a "ghost" local address)

Yong Huang

-----Original Message-----

of the 3 DNS servers for this client databases. This caused very long wait times where some people thought the listener was hung and or the databases were down. Listener and databases never were down. They said they were using 3 servers in a round-robin fashion.

They replaced the server and things were fine again. Someone asked what "oracle" did when there was an issue with DNS and all I found so far was this RAC pdf It stated:
Note: If your DNS server does not return a set of 3 IPs as shown in figure 3 or does not round-robin, ask your network administrator to enable such a setup. DNS using a round-robin algorithm on its own does not ensure failover of connections. However, the Oracle Client typically handles this. It is therefore recommended that the minimum version of the client used is the Oracle Database 11g Release 2 client.

It seems to me this should work the same way RAC or not. But some other DBAs said it only works that way for RAC.

Can someone clarify this and can anyone point me to a better document?

Did I miss this in
Oracle(r) Database
Net Services Administrator's Guide
11g Release 2 (11.2)


The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged.

If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system.

Thank You.

Received on Thu May 24 2012 - 15:50:06 CDT

Original text of this message