Shulou(Shulou.com)06/01 Report--

Analysis of database connection delay caused by domain name resolution

I. record of current situation

[oracle@node1 ~] $/ sbin/ifconfig eth2 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)-the IP address is 192.168.9.140 [oracle@node1 ~] $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 localhost 192.168.9.140 node1.srtcloud.com-the domain name node1.srtcloud.com corresponds to ip192.168.9.140 [oracle@node1 ~] $lsnrctl status Connecting to (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=node1.srtcloud.com) (PORT=1521) STATUS of the LISTENER-Alias LISTENER Version TNSLSNR for Linux: Version 10.2.0.5.0- Production Start Date 04-NOV-2011 09:08:51 Uptime 21 days 4 hr. 58 min. 45 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File / opt/oracle/product/10.2.0/db_1/network/admin/listener.ora Listener Log File / opt/oracle/product/10.2.0/db_1/network/log/listener.log Listening 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-description: ora11g is oracle 11g opt/oracle/product/10.2.0/db_1/network/admin/tnsnames.ora ECP is oracle 10g-currently using the domain name node1.srtcloud.com to listen [oracle@node1 ~] $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 also accesses [oracle@node1 ~] through the domain name $more / etc/resolv.conf nameserver 211.155.235.201 nameserver 211.155.235.188-- currently valid dns server [oracle@node1 ~] $more / etc/nsswitch.conf | grep hosts: hosts: files dns-- Domain name resolution order

II. Analysis of the normal work of the database

1. Tns works: the client accesses the database through tns, and tns configures domain name access, so it needs to be resolved. Because the order of resolution is to use / etc/hosts resolution first, read the hosts file, get the ip, then access the corresponding database, and monitor the contact.

2. Monitoring work: the domain name is monitored, but it is also resolved to ip through hosts

3. It works normally here because the hosts file resolves the domain name.

Third, simulate database access latency

[oracle@node1 ~] $more / etc/nsswitch.conf | grep hosts: hosts: dns files-- parse using dns server first, then use hosts file [oracle@node1 ~] $more / etc/resolv.conf nameserver 11.1.1.1-- invalid dns server [oracle@node1 ~] $sqlplus chf/xifenfei@ora11g SQL*Plus: Release 10.2.0.5.0-Production on Fri Nov 25 14:44:55 2011 Copyright (c) 1982, 2010, Oracle. All Rights Reserved. Will be waiting here for a long time [oracle@node1] $lsnrctl status LSNRCTL for Linux: Version 10.2.0.5.0-Production on 25-NOV-2011 14:48:26 Copyright (c) 1991, 2010, Oracle. All rights reserved. Connecting to (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=node1.srtcloud.com) (PORT=1521)-- there will also be a long wait-- the reason for the problem: when resolving a domain name, we first access the dns server, because the ip is not a dns server ip, so we wait for the IP timeout all the time-- and then access the hosts file to get the ip address (which is why we log in or check the listening status There will be such a long wait)

In fact, because there are many kinds of dns delays, I just cited the simplest and more common example here. When dealing with snooping delays due to dns parsing, you can refer to the following points:

1. If it is not a special case, use the ip address in monitoring and tns whenever possible

2. If you are using a domain name, please use hosts resolution as much as possible. The resolution order is configured as files priority (because the dns server has a lot of uncertainties and uncontrollable factors)

3. If you must use a dns server for resolution, please configure a stable dns server in the first item to avoid the phenomenon that the dns server is unreachable or the domain name does not exist.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.