当前位置: 首页 > Oracle, oracle 11g > 正文

监听响应异常故障解决

昨天帮一个汽车金融公司解决了一个用户登录异常缓慢的故障,用户通过应用程序访问数据库异常缓慢,通过PLSQL Developer登录也需要20多秒才能登录。尝试通过操作系统认证的方式登录数据库没有问题。数据库版本11.2.0.1.0,操作系统红帽linux 5.8。

[oracle@xxx ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Aug 8 15:47:24 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning option

SQL>
[oracle@xxx ~]$ sqlplus user/password

SQL*Plus: Release 11.2.0.1.0 Production on Fri Aug 8 15:48:54 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning option

在服务器上直接访问数据库没有任何问题,很快就可登录。查看AWR报告也未发现异常。

00142

从这部分信息可以看出,数据库相当的闲,基本没有什么业务,从snap id可以看出,这个库刚创建不久,问了相关人员,他们说这是新建的库,数据刚迁过来,具体什么时候开始有这个问题的竟然没人知道,就说最近就很慢。

下面在看看,数据库的负载信息。

00143

多么闲的系统啊,数据库基本没有什么负载。再看看等待事件。

00144

也没有发现异常的等待,看了下后台进程的等待,也没发现异常,基本可以断定,问题不是出在数据库层面。

在服务器上通过监听登录数据库,问题出现,特别慢。

[oracle@xxx ~]$ sqlplus user/password@localhost/xxx     --此处卡住大约20秒

SQL*Plus: Release 11.2.0.1.0 Production on Fri Aug 8 16:04:22 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning option

SQL>

问题很明显是出在网络层面,通过ping命令发现网络很好,延迟都非常小,排除由于网络带宽不足导致登录缓慢。查看监听,发现竟然没有监听文件,监听通过默认值启动(不影响使用)。

这简单描述下监听的三要素,这要这三要素具备,监听就可以工作。这三要素分别是协议、主机名、端口号。协议默认是TCP协议,主机名默认是当前的主机,端口号默认是1521。这些数据默认值都知道了,虽然没有监听文件,监听一样可以起来并提供工作。

配置监听文件后,重新启动监听,重启监听后,如果没有配置静态注册,数据库服务不会立即之策到监听上,需要到数据库里注册,或者过两分钟,PMON进程会主动将数据库服务推送给监听器,如果配了静态注册,就不需要了。

SQL> alter system register;
System Altered.

再次通过监听连接数据库,问题依旧。检查hosts文件,发现hosts文件配置的有点问题。

[root@xxx ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               xxx localhost.localdomain localhost
10.0.11.1              localhost6.localdomain6 localhost6

修改hosts文件,讲IP地址后面改成主机名。

[root@xxx ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               xxx localhost.localdomain localhost
#10.0.11.1              localhost6.localdomain6 localhost6
10.0.11.1		  	    xxx

通过监听连接数据库,问题没有解决,还是很慢,设置监听的trace,通过监控监听,看看到底是哪慢。

[oracle@xxx ~]$ lsnrctl

LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 08-AUG-2014 16:10:06

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> set trc_level support
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx)(PORT=1521)))
LISTENER parameter "trc_level" set to support
The command completed successfully

通过status命令查看当前使用的trace文件。

LSNRCTL> status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.1.0 - Production
Start Date                09-AUG-2014 16:10:30
Uptime                    0 days 0 hr. 1 min. 19 sec
Trace Level               support
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/diag/tnslsnr/xxx/listener/alert/log.xml
Listener Trace File       /u01/app/oracle/diag/tnslsnr/xxx/listener/trace/ora_6273_3043251904.trc
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xxx)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "xxx" has 1 instance(s).
  Instance "xxx", status READY, has 1 handler(s) for this service...
The command completed successfully

通过在另一个窗口监控这个文件,在其他窗口通过监听登录数据库,发现卡住的时候的监听日志信息如下:

2014-08-07 16:15:47.197635 : nsevfnt:cxd: 0xff4d2f8 stage 0: NS events set:
2014-08-07 16:15:47.197656 : ntpctl:entry
2014-08-07 16:15:47.197681 : sntpcall:result string is NTP0 6879
2014-08-07 16:15:47.197708 : sntpcall:exit
2014-08-07 16:15:47.197728 : ntpctl:exit
2014-08-07 16:15:47.197767 : nttaddr2bnd:entry
2014-08-07 16:15:47.197789 : snlinGetNameInfo:entry
2014-08-07 16:15:47.197814 : snlinGetNameInfo:exit
2014-08-07 16:15:47.197835 : nttaddr2bnd:Resolved to 10.0.11.1
2014-08-07 16:15:47.197860 : nttaddr2bnd:exit
2014-08-07 16:15:47.197887 : nsbequeath_stg2:doing connect handshake...
2014-08-07 16:15:47.197909 : nsbequeath:doing connect handshake...
2014-08-07 16:15:47.197930 : ntpwr:entry
2014-08-07 16:15:47.197959 : ntpwr:exit
2014-08-07 16:15:47.197983 : ntpwr:entry
2014-08-07 16:15:47.198011 : ntpwr:exit
2014-08-07 16:15:47.198032 : ntpwr:entry
2014-08-07 16:15:47.198056 : ntpwr:exit
2014-08-07 16:15:47.198077 : ntprd:entry
2014-08-07 16:16:07.199138 : ntprd:exit
2014-08-07 16:16:07.199239 : ntprd:entry
2014-08-07 16:16:07.199469 : ntprd:exit

当sqlplus卡住的时候,监听日志就卡在这里了,看到的都是ntp相关的信息,我首先想到的是是不是由于ntp服务器导致的呢?好像解释不通,不过他们还真配置了NTP服务,停掉NTP服务后,问题还是没有解决。思路再回到刚才的网络上,这个现象通常都和解析有关,那么都改好了hosts解析了,为什么还这么慢呢?难道是没有使用hosts解析?检查服务器是否配置了DNS。

[root@xxx ~]# cat /etc/resolv.conf
nameserver 10.254.10.18
nameserver 10.0.1.73

可见,服务器上配置了两个DNS,这样,在访问数据库的时候,就不会优先使用hosts文件进行解析,由于时间有限,我并没有检查是DNS的IP地址不通还是网络延迟较大还是这个DNS解析不了这个主机,才会导致的问题,既然已经猜到是DNS导致的问题,那么就禁掉这两个DNS,让服务器使用hosts文件去解析。

[root@xxx ~]# cat /etc/resolv.conf
#nameserver 10.254.10.18
#nameserver 10.0.1.73

禁掉DNS后,在主机上通过监听登录数据库并没有经历漫长的等待,在其他客户机上访问数据库都很正常,应用服务器连接数据库也很正常,问题解决。

本文固定链接: http://www.dbdream.com.cn/2015/01/%e7%9b%91%e5%90%ac%e5%93%8d%e5%ba%94%e5%bc%82%e5%b8%b8%e6%95%85%e9%9a%9c%e8%a7%a3%e5%86%b3-2/ | 信春哥,系统稳,闭眼上线不回滚!

该日志由 dbdream 于2015年01月04日发表在 Oracle, oracle 11g 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 监听响应异常故障解决 | 信春哥,系统稳,闭眼上线不回滚!
关键字: , , , , ,

监听响应异常故障解决:等您坐沙发呢!

发表评论

快捷键:Ctrl+Enter