DNS设置引起的登录延迟

一套Linux上的11.1.0.7系统，操作系统管理人员最近对该服务器上的网络配置文件/etc/nsswitch.conf进行了调整，调整前其主机名解析选项为"hosts:files dns" ，调整后被修改成了"hosts:files [NOTFOUND=continue] dns"；此后应用人员尝试在该主机上使用 "sqlplus username/password@connect_string"远程登录数据库都会出现多达五分钟的延迟，使用lsnrctl status命令查看监听器状态，发现LISTENER一切正常；初步可以判断是dns解析导致了长时间的延迟。 针对以上问题，首先想到的是设置client端Oracle network trace以了解造成延迟的具体原因,在$ORACLE_HOME/network/admin/sqlnet.ora配置文件中加入以下记录:

?

1 2 3 4 5

TRACE_LEVEL_CLIENT = 16 TRACE_FILE_CLIENT = client TRACE_DIRECTORY_CLIENT = [ any  valid directory path] TRACE_TIMESTAMP_CLIENT =  ON DIAG_ADR_ENABLED= off

之后再次尝试登录就会触发Oracle Network Trace文件在$TRACE_DIRECTORY_CLIENT指定的目录下产生(如果DIAG_ADR_ENABLED未设置为false，那么11g下TRACE_DIRECTORY_CLIENT并不生效，而会产生在11g特有的diag目录下)。 登录测试产生的trace文件记录:

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71

[02-SEP-2010 07:36:57:719] nsc2addr: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=m218279apss2012-vip)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=MOTOIDP.MOT.COM)(INSTANCE_NAME=MOTOIDP1)(CID=(PROGRAM=sqlplus)(HOST=m218279apss2012.mot.com)( USER =oraoid)))) [02-SEP-2010 07:36:57:719] nttbnd2addr: entry [02-SEP-2010 07:36:57:719] snlinGetAddrInfo: entry [02-SEP-2010 07:36:57:719] snlinGetAddrInfo: getaddrinfo() failed  with  error -2 [02-SEP-2010 07:36:57:719] snlinGetAddrInfo: exit [02-SEP-2010 07:36:57:719] nttbnd2addr: looking up IP addr  for  host: m218279apss2012-vip [02-SEP-2010 07:36:57:719] snlinGetAddrInfo: entry [02-SEP-2010 07:36:57:719] snlinGetAddrInfo: exit [02-SEP-2010 07:36:57:719] snlinFreeAddrInfo: entry [02-SEP-2010 07:36:57:719] snlinFreeAddrInfo: exit [02-SEP-2010 07:36:57:719] nttbnd2addr: exit .................. [02-SEP-2010 07:36:57:722] nspsend: packet dump [02-SEP-2010 07:36:57:722] nspsend: 01 1E 00 00 01 00 00 00  |........| [02-SEP-2010 07:36:57:722] nspsend: 01 3A 01 2C 0C 41 20 00  |.:.,.A..| [02-SEP-2010 07:36:57:722] nspsend: 7F FF 7F 08 00 00 01 00  |........| [02-SEP-2010 07:36:57:722] nspsend: 00 E4 00 3A 00 00 02 00  |...:....| [02-SEP-2010 07:36:57:722] nspsend: 41 41 00 00 00 00 00 00  |AA......| [02-SEP-2010 07:36:57:722] nspsend: 00 00 00 00 00 00 00 00  |........| [02-SEP-2010 07:36:57:722] nspsend: 00 00 00 00 00 00 00 00  |........| [02-SEP-2010 07:36:57:722] nspsend: 00 00 28 44 45 53 43 52  |..(DESCR| [02-SEP-2010 07:36:57:722] nspsend: 49 50 54 49 4F 4E 3D 28  |IPTION=(| [02-SEP-2010 07:36:57:722] nspsend: 41 44 44 52 45 53 53 3D  |ADDRESS=| [02-SEP-2010 07:36:57:722] nspsend: 28 50 52 4F 54 4F 43 4F  |(PROTOCO| [02-SEP-2010 07:36:57:722] nspsend: 4C 3D 54 43 50 29 28 48  |L=TCP)(H| [02-SEP-2010 07:36:57:722] nspsend: 4F 53 54 3D 6D 32 31 38  |OST=m218| [02-SEP-2010 07:36:57:722] nspsend: 32 37 39 61 70 73 73 32  |279apss2| [02-SEP-2010 07:36:57:722] nspsend: 30 31 32 2D 76 69 70 29  |012-vip)| [02-SEP-2010 07:36:57:722] nspsend: 28 50 4F 52 54 3D 31 35  |(PORT=15| [02-SEP-2010 07:36:57:722] nspsend: 32 31 29 29 28 43 4F 4E  |21))(CON| [02-SEP-2010 07:36:57:722] nspsend: 4E 45 43 54 5F 44 41 54  |NECT_DAT| [02-SEP-2010 07:36:57:722] nspsend: 41 3D 28 53 45 52 56 45  |A=(SERVE| [02-SEP-2010 07:36:57:722] nspsend: 52 3D 44 45 44 49 43 41  |R=DEDICA| [02-SEP-2010 07:36:57:722] nspsend: 54 45 44 29 28 53 45 52  |TED)(SER| [02-SEP-2010 07:36:57:722] nspsend: 56 49 43 45 5F 4E 41 4D  |VICE_NAM| [02-SEP-2010 07:36:57:722] nspsend: 45 3D 4D 4F 54 4F 49 44  |E=MOTOID| [02-SEP-2010 07:36:57:722] nspsend: 50 2E 4D 4F 54 2E 43 4F  |P.MOT.CO| [02-SEP-2010 07:36:57:722] nspsend: 4D 29 28 49 4E 53 54 41  |M)(INSTA| [02-SEP-2010 07:36:57:722] nspsend: 4E 43 45 5F 4E 41 4D 45  |NCE_NAME| [02-SEP-2010 07:36:57:722] nspsend: 3D 4D 4F 54 4F 49 44 50  |=MOTOIDP| [02-SEP-2010 07:36:57:722] nspsend: 31 29 28 43 49 44 3D 28  |1)(CID=(| [02-SEP-2010 07:36:57:722] nspsend: 50 52 4F 47 52 41 4D 3D  |PROGRAM=| [02-SEP-2010 07:36:57:722] nspsend: 73 71 6C 70 6C 75 73 29  |sqlplus)| [02-SEP-2010 07:36:57:722] nspsend: 28 48 4F 53 54 3D 6D 32  |(HOST=m2| [02-SEP-2010 07:36:57:722] nspsend: 31 38 32 37 39 61 70 73  |18279aps| [02-SEP-2010 07:36:57:722] nspsend: 73 32 30 31 32 2E 6D 6F  |s2012.mo| [02-SEP-2010 07:36:57:722] nspsend: 74 2E 63 6F 6D 29 28 55  |t.com)(U| [02-SEP-2010 07:36:57:722] nspsend: 53 45 52 3D 6F 72 61 6F  |SER=orao| [02-SEP-2010 07:36:57:722] nspsend: 69 64 29 29 29 29        |id))))  | [02-SEP-2010 07:36:57:722] nspsend: 286 bytes  to  transport [02-SEP-2010 07:36:57:722] nspsend: normal exit [02-SEP-2010 07:36:57:722] nscon: exit (0) [02-SEP-2010 07:36:57:722] nsdo: nsctxrnk=0 [02-SEP-2010 07:36:57:722] nsdo: normal exit [02-SEP-2010 07:36:57:722] nsdo: entry [02-SEP-2010 07:36:57:722] nsdo: cid=0, opcode=68, *bl=512, *what=9, uflgs=0x0, cflgs=0x3 [02-SEP-2010 07:36:57:722] nsdo: rank=64, nsctxrnk=0 [02-SEP-2010 07:36:57:722] nsdo: nsctx: state=2, flg=0x4005, mvd=0 [02-SEP-2010 07:36:57:722] nsdo: gtn=10, gtc=10, ptn=10, ptc=8155 [02-SEP-2010 07:36:57:722] nscon: entry [02-SEP-2010 07:36:57:722] nscon: recving a packet [02-SEP-2010 07:36:57:722] nsprecv: entry [02-SEP-2010 07:36:57:722] nsprecv: reading  from  transport... [02-SEP-2010 07:36:57:722] nttrd: entry [02-SEP-2010 07:41:57:741] nttrd: socket 9 had bytes  read =8 [02-SEP-2010 07:41:57:741] nttrd: exit [02-SEP-2010 07:41:57:741] nsprecv: 8 bytes  from  transport [02-SEP-2010 07:41:57:741] nsprecv: tlen=8, plen=8, type=11 [02-SEP-2010 07:41:57:741] nsprecv: packet dump [02-SEP-2010 07:41:57:741] nsprecv: 00 08 00 00 0B 00 00 00  |........| [02-SEP-2010 07:41:57:741] nsprecv: normal exit

可以看到以上出现了"snlinGetAddrInfo: getaddrinfo() failed with error -2"的记录，通过关键词"snlinGetAddrInfo"在MOS上搜索可以找到以下Note:

Remote Connections Take Very Long to Establish

Applies to:

Oracle Net Services - Version: 11.1.0.6 to 11.1.0.7 - Release: 11.1 to 11.1 Information in this document applies to any platform.

Symptoms

When you connect remotely, it takes very long until the connection is established. Once connected, everything works fine. Local bequeath connections work in a timely manner. Resolution of hostnames is done via a centralized  DNS server.

Cause

Listener traces show the listener is wasting time while calling the " snlinGetAddrInfo" function :

2009-07-08

本文转自maclean_007 51CTO博客，原文链接:http://blog.51cto.com/maclean/1277553