锐客网

  1. 首页 > 睿知 > it技术 > >

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

IT知识数据库Listener

识字粗堪供赋役，不须辛苦慕公卿。这篇文章主要讲述Oracle Scan Listener过大导致的数据库Hang相关的知识，希望能为你提供帮助。
早高峰接到通知业务系统发生故障，科室处于无法使用的状态，管理员怀疑是发生了死锁导致。接到通知第一时间进行响应，远程登录到业务系统进行故障排查，现将排查过程进行记录。
1、环境介绍
操作系统：RedHat Linux 6.8
数据库：Oracle 11.2.0.4
高可用模式：3节点Rac
2、故障定位处理
按照客户的的怀疑，首先进行三个节点的系统登录，在节点1和节点3登录到数据库通过死锁脚本进行查询发现大量的事务所等待，持续时间比较长，如图：

然后登录节点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】


    推荐阅读


    上一篇：云原生网络架构

    下一篇：VMware vSphere Client