Database connection Latency analysis due to domain name resolution

First, the status record

[[email protected] ~]$ /sbin/ifconfigeth1      Link encap:Ethernet  HWaddr 00:25:90:04:AB:6B            inet addr:192.168.9.140  Bcast:192.168.15.255  Mask:255.255.248.0          inet6 addr: fe80::225:90ff:fe04:ab6b/64 Scope:Link          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:23530402 errors:0 dropped:0 overruns:0 frame:0          TX packets:10959123 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0           RX bytes:15308483748 (14.2 GiB)  TX bytes:10087987532 (9.3 GiB)--IP地址为192.168.9.140 [[email protected] ~]$ more /etc/hosts# Do not remove the following line, or various programs# that require network functionality will fail.127.0.0.1               ecp-db localhost.localdomain localhost192.168.9.140   node1.srtcloud.com--域名node1.srtcloud.com对应ip192.168.9.140 [[email protected] ~]$ lsnrctl statusConnecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1.srtcloud.com)(PORT=1521)))STATUS of the LISTENER------------------------Alias                     LISTENERVersion                   TNSLSNR for Linux: Version 10.2.0.5.0 - ProductionStart Date                04-NOV-2011 09:08:51Uptime                    21 days 4 hr. 58 min. 45 secTrace Level               offSecurity                  ON: Local OS AuthenticationSNMP                      OFFListener Parameter File   /opt/oracle/product/10.2.0/db_1/network/admin/listener.oraListener Log File         /opt/oracle/product/10.2.0/db_1/network/log/listener.logListening Endpoints Summary...  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=node1.srtcloud.com)(PORT=1521)))Services Summary...Service "ecp" has 2 instance(s).  Instance "ecp", status UNKNOWN, has 1 handler(s) for this service...  Instance "ecp", status READY, has 1 handler(s) for this service...Service "ecpXDB" has 1 instance(s).  Instance "ecp", status READY, has 1 handler(s) for this service...Service "ecp_XPT" has 1 instance(s).  Instance "ecp", status READY, has 1 handler(s) for this service...Service "ora11g" has 2 instance(s).  Instance "ora11g", status UNKNOWN, has 1 handler(s) for this service...  Instance "ora11g", status READY, has 1 handler(s) for this service...Service "ora11gXDB" has 1 instance(s).  Instance "ora11g", status READY, has 1 handler(s) for this service...The command completed successfully--说明:ora11g是oracle 11g，ecp是oracle 10g--当前使用域名node1.srtcloud.com监听[[email protected] ~]$ more /opt/oracle/product/10.2.0/db_1/network/admin/tnsnames.ora # tnsnames.ora Network Configuration File: /opt/oracle/product/10.2.0/db_1/network/admin/tnsnames.ora# Generated by Oracle configuration tools.ECP =  (DESCRIPTION =    (ADDRESS = (PROTOCOL = TCP)(HOST = node1.srtcloud.com)(PORT = 1521))    (CONNECT_DATA =      (SERVER = DEDICATED)      (SERVICE_NAME = ecp)    )  )ORA11G =  (DESCRIPTION =    (ADDRESS = (PROTOCOL = TCP)(HOST = node1.srtcloud.com)(PORT = 1521))    (CONNECT_DATA =      (SERVER = DEDICATED)      (SERVICE_NAME = ora11g)    )  )--tns也通过域名访问[[email protected] ~]$ more /etc/resolv.conf nameserver 211.155.235.201nameserver 211.155.235.188--当前有效的dns服务器[[email protected] ~]$ more /etc/nsswitch.conf |grep hosts:hosts:     files dns--域名解析顺序

Second, the normal work of the database analysis
1, TNS work: The client through TNS access to the database, TNS configuration is the domain name access, so need to parse, because the order of resolution is the first to use/etc/hosts parsing, so read the Hosts file, get to IP, then access the corresponding database, and listen to contact.
2, monitoring work: monitoring is the domain name, in fact, through the hosts to resolve the IP
3, here can work normally, because the Hosts file resolves the domain name

Third, analog database access delay

[[email protected] ~]$ more /etc/nsswitch.conf |grep hosts:hosts:     dns files--先使用dns服务器解析，再使用hosts文件[[email protected] ~]$ more /etc/resolv.conf nameserver 11.1.1.1--无效的dns服务器[[email protected] ~]$ sqlplus chf/xifenfei@ora11gSQL*Plus: Release 10.2.0.5.0 - Production on Fri Nov 25 14:44:55 2011Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.--会在这里一个很长的时间等待[[email protected] ~]$ lsnrctl statusLSNRCTL for Linux: Version 10.2.0.5.0 - Production on 25-NOV-2011 14:48:26Copyright (c) 1991, 2010, Oracle.  All rights reserved.Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1.srtcloud.com)(PORT=1521)))--也会一个长时间的等待--问题原因:就是因为解析域名的时候，先去访问dns服务器，因为该ip非dns服务器ip，所以会一直等待该ip超时，--然后访问hosts文件获取ip地址（这个就是为什么我们登录或者查看监听状态的时候，会出现如此长的时间的等待）

In fact, because of the phenomenon of DNS latency There are many kinds of, I just give a simple, more common example, in the processing due to DNS resolution of the monitoring delay problem, you can refer to the following points:
1, if not special circumstances, as far as possible to use the IP address in monitoring and TNS
2, if the use of the domain name, please use the hosts to resolve, the resolution sequence is configured as files priority (because the DNS server has a lot of uncertainties, uncontrolled factors)
3, if you must use DNS server resolution, please configure the stable DNS server in the first, as far as possible to avoid the DNS server is unreachable or does not exist the phenomenon of the domain name

Ext.: http://www.xifenfei.com/2011/11/%e5%9b%a0%e5%9f%9f%e5%90%8d%e8%a7%a3%e6%9e%90%e5%af%bc%e8%87%b4%e6%95%b0%e6% 8d%ae%e5%ba%93%e8%bf%9e%e6%8e%a5%e5%bb%b6%e8%bf%9f%e5%88%86%e6%9e%90.html

Database connection Latency analysis due to domain name resolution