Oracle Scan Listener过大导致的数据库Hang

Posted xzcanys

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Oracle Scan Listener过大导致的数据库Hang相关的知识,希望对你有一定的参考价值。

早高峰接到通知业务系统发生故障,科室处于无法使用的状态,管理员怀疑是发生了死锁导致。接到通知第一时间进行响应,远程登录到业务系统进行故障排查,现将排查过程进行记录。

1、环境介绍

操作系统:RedHat Linux 6.8

数据库:Oracle 11.2.0.4

高可用模式:3节点Rac

2、故障定位处理

按照客户的的怀疑,首先进行三个节点的系统登录,在节点1和节点3登录到数据库通过死锁脚本进行查询发现大量的事务所等待,持续时间比较长,如图:

Oracle

然后登录节点2,当通过系统权限(sqlplus / as sysdba)登录数据库时候发现提示用户名密码错误,使用的系统权限无法登录,然后尝试用户名密码登录依旧是无法登录。

进行节点2的trace日志分析,在日志里面发现如下报错:

Non critical error ORA-48181 caught while writing to trace file "/u01/app/oracle/diag/rdbms/xiaozc/xiaozc2/trace/xiaozc2_ora_19545.trc"

Error message: Linux-x86_64 Error: 28: No space left on device

Additional information: 1

Writing to the above trace file is disabled for now on...

出乎意料的提示没有剩余空间,难道又碰到了inode节点不足的问题了,马上执行df -i进行系统inode节点查看,结果发现并不是inode满导致的,inode利用率非常低,如下所示:

[root@xiaozc2 alert]# df -i

Filesystem       Inodes          IUsed        IFree         IUse% Mounted on

/dev/sda5      10772480       61307       10711173    1%       /

tmpfs            16497312        416          16496896    1%      /dev/shm

/dev/sda1        128016          39           127977        1%     /boot

/dev/sda2       6406144        60629       6345515      1%      /u01

不是inode节点的问题,然后通过df -h查看空间,果不其然,空间满了,/u01目录还剩余1M空间,如下所示:

[root@xiaozc2 alert]# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/sda5       162G  3.8G  150G   3% /

tmpfs            63G  533M   63G   1% /dev/shm

/dev/sda1       477M   42M  410M  10% /boot

/dev/sda2        96G   96G   1M  100% /u01

具体是什么文件占用了这么大的空间呢,进入/u01目录进行查看,通过du -sh命令发现/u01/app/11.2.0/grid/log目录占用了66G,然后继续查找占用空间大的具体文件发现是scan监听生成的日志文件,如下所示:

[oracle@xiaozc2 trace]$ cd /u01/app/11.2.0/grid/log/diag/tnslsnr/xiaozc2/listener_scan1/

[oracle@xiaozc2 listener_scan1]# du -sh ./*

42G ./alert

4.0K ./cdump

4.0K ./incident

4.0K ./incpkg

4.0K ./lck

264K ./metadata

4.0K ./metadata_dgif

4.0K ./metadata_pv

4.0K ./stage

4.0K ./sweep

23G ./trace

[oracle@xiaozc2 listener_scan1]$ cd alert

[oracle@xiaozc2 alert]# du -sh  --alter日志下边的xml文件占用了42G

42G .

oracle@hisdb2 trace]$ pwd

/u01/app/11.2.0/grid/log/diag/tnslsnr/xiaozc2/listener_scan1/trace

[oracle@xiaozc2 trace]$ ls -rtlh  --scan监听日志占用了23G

total 23G

-rw-r----- 1 grid oinstall 23G May 23 14:01 listener_scan1.log

为了尽快恢复业务,清除监听日志文件置换空间,如下操作

[root@xiaozc2 alert]# rm -rf log_1*.xml

[root@xiaozc2 alert]# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/sda5       162G  3.8G  150G   3% /

tmpfs            63G  533M   63G   1% /dev/shm

/dev/sda1       477M   42M  410M  10% /boot

/dev/sda2        96G   81G   11G  89% /u01

至此,通知客户进行业务测试,反馈所有科室业务恢复正常。确认业务正常后后对所有节点监听日志文件进行了维护。

3、总结

由于监听日志默认为开启状态,随着时间的推移,监听日志log文件会越来越大,而且还会还会伴随着xml文件的生成,若不定期进行清理,很有可能会导致空间爆满影响数据库的正常运行,除此之外,监听日志过大也有可能导致连接不稳定的情况发生。此次问题发生就是由于监听日志过大占用了大量空间引起了数据库hang,建议管理员定期对业务系统进行巡检,避免不必要的宕机风险。




以上是关于Oracle Scan Listener过大导致的数据库Hang的主要内容,如果未能解决你的问题,请参考以下文章

Oracle11g监听器日志 listener.log文件过大处理

scan listener 重启

如何删除oracle监听日志

Oracle 11gR2 RAC监听器原理介绍

SCAN 原理小节

ORACLE数据库逐步解决ORA-12541ORA-01034和ORA-27101ORA-00119和ORA00132的过程