Document 1449843.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-st...

Copyright (c) 2024, Oracle. All rights reserved. Oracle Confidential.

Reducing Client Connection Delays When DNS Is Unresponsive (Doc ID 1449843.1)

In this Document

Goal
Solution
References

APPLIES TO:

Oracle Cloud Infrastructure - Database Service - Version N/A and later

Oracle Database Backup Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
JDBC - Version 11.2.0.4.0 to 12.1.0.2.0 [Release 11.2 to 12.1]
Information in this document applies to any platform.

GOAL

In Oracle RAC clients frequently use DNS to resolve a scan name to one of three scan listener IP addresses.

Scan address setup in DNS

[mseibt@netbde]$ nslookup scan

..
Name: scan.example.com
Address: <SCAN IP address 1>
Name: scan.example.com
Address: <SCAN IP address 2>
Name: scan.example.com
Address: <SCAN IP address 3>

In situations where the primary nameserver is down, to perform maintenance for example, client connectivity and any
operation involving resolution of the scan name may experience a delay. The delay is at the OS level since the DNS
query must timeout and then failover to the secondary or backup nameserver.

There are multiple areas that can be tuned to mitigate client connection delays when a nameserver is down. These tips
and solutions are also helpful in non-RAC environments.

SOLUTION

1) Reduce the DNS query timeout at the OS.

Example: Linux

The "options" settings in resolv.conf provide for additional tuning of nameserver query timeouts.

timeout:n
sets the amount of time the resolver will wait for a response from a remote name server before retrying the
query via a different name server.

attempts:n
sets the number of times the resolver will send a query to its name servers before giving up and returning an
error to the calling application.

/etc/resolv.conf

1 of 4 04/06/2024, 09:29
Document 1449843.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-st...

search example.com
nameserver <NAME SERVER IP ADDRESS>
nameserver <NAME SERVER IP ADDRESS>
options timeout:1
options attempts:1

Example: HPUX:

/etc/resolv.conf

retrans 1000 (Note that the default is 5000ms or 5 seconds)

retry 1 (Note that the default is 4)

2) Enable the clients system-level name resolution cache.

With a caching mechanism in place the client will check the cache before going to DNS when resolving scan or vip
hostnames. If the primary DNS is down and the hostname is not cached the client will initially go to DNS which will
then update the cache, successive lookups for the same hostname will no longer be subject to failover delays going to
DNS.

Example: Linux

/usr/sbin/nscd - name service cache daemon

configure - tune: /etc/nscd.conf

[mseibt@netbde]$ sudo service nscd status

nscd is stopped

[mseibt@netbde]$ sudo service nscd start

Starting nscd: [ OK ]

[mseibt@netbde]$ sudo chkconfig nscd on (automatically starts nscd after reboot)

NSCD (name service cache daemon) is available on Linux, Solaris, AIX and HP-UX platforms. The daemon should be
configured to start automatically after reboot. For more details on how to configure (and tune) NSCD refer to your
operating system documentation.

3) Use an address_list in the (scan) connect descriptor.

DNS requests to resolve the scan name are made by the Oracle Net function snlinGetAddrInfo. When an address_list is
not used in the connect descriptor snlinGetAddrInfo invokes two separate DNS queries during the connection process.
If the primary nameserver is down or offline each of those queries will go through a failover sequence. When
address_list syntax is used snlinGetAddrInfo will make only one query (reducing the cumulative delay).

Example: connect descriptor using address_list.

RAC =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = rac.example.com)
)
)

4) Restrict protocol usage.

On systems running side-by-side implementations of IPv4 and IPv6 (known as dual stack) both IPv4 and IPv6 address

2 of 4 04/06/2024, 09:29
Document 1449843.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-st...

families may attempt to contact DNS servers. Protocols on dual stack systems can be restricted to a single protocol
family by specifying "(IP=V4_ONLY)" or "(IP=V6_ONLY)" in the client side connect descriptor.

Example: restricting hostname resolution to IPv4 (DNS queries over IPv6 will not be performed.)

RAC =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = scan)(PORT = 1521)(IP=V4_ONLY))
)
(CONNECT_DATA =
(SERVICE_NAME = rac.example.com)
)
)

Usage of "(IP=V4_ONLY)" or "(IP=V6_ONLY)" in the client connect descriptor is fully supported in Oracle versions
11.2.0.4 and later. Protocol restriction support in 11.2.0.2 and 11.2.0.3 requires the installation of patch 13900991.

5) In situations where nameserver uptime is questionable or when a DNS delay might create a problem the client
connect descriptor can be configured to load balance connections with scan listeners using their IP addresses. This
technique is also used with pre-11.2 clients.

Example: connect descriptor using scan listener IP addresses.

RAC =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=on)(FAILOVER=ON)
(ADDRESS=(PROTOCOL=tcp)(HOST=<SCAN IP address 1>)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=<SCAN IP address 2>)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=<SCAN IP address 3>)(PORT=1521))
)
(CONNECT_DATA=(SERVICE_NAME= rac.example.com))
)

There is an additional DNS query performed after the client is redirected by the scan listener to the vip/database
listener. The scan listener supplies the client with the vip name which the client must again resolve through DNS.
Having each of the node vip names mapped to IPs in the client /etc/hosts file will suppress the DNS query provided
nsswitch.conf is configured to use files before dns.

hosts: files dns

This workaround is suitable perhaps for a single or small group of systems (e.g., application servers) and will
eliminate a bit more of any DNS related connection delays.

6) JDBC thin driver architecture differs from OCI in that the Listener must perform a DNS query with each incoming
(JDBC thin) client connection. In that situation and if DNS response is slow all incoming client connections through the
listener may be affected or delayed including other coinciding OCI connections. A recent performance enhancement to
the JDBC thin client modifies the connection properties to lessen this DNS dependency at the listener. This improved
JDBC connection behavior takes effect starting with Oracle 12.1.0.2.0 but the same enhancement can also be
backported to earlier versions using bug 18369949.

3 of 4 04/06/2024, 09:29
Document 1449843.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-st...

REFERENCES

NOTE:18369949.8 - Bug 18369949 - Slow connection of JDBC using dns lookup

BUG:13900991 - THE CLIENT QUERIES DNS SERVER WITH TYPE IPV6 TO RESOLVE THE SCAN IP.
NOTE:2051087.1 - "Socket read timed out" Error Trying to Connect from JDBC Application
Didn't find what you are looking for?

4 of 4 04/06/2024, 09:29