数据库hang分析
大家好!我是本际云服务器推荐网的小编小本本。最近我们遇到了一起数据库hang的故障,现在跟大家分享一下处理思路。

分析过程
某日,同事反馈数据库节点2有很多cursor:pinSwaitonX异常等待事件,与此同时librarycachelock也伴随出现;会话开始出现积压,应用反馈应用异常。登录数据库主机发现节点1正常、节点2异常。接下来我们开始对故障进行分析:
堵塞链分析
首先,查看hanganalyze日志,发现都是在等待rowcachelock。接着,继续查看堵塞链:
- Chain1:堵塞源是节点2,SID:1215的会话,此时它堵塞了195个会话,其正在等待cacheid:0X10的ROWCACHE。
- Chain2:堵塞源是节点2,SID:2419的会话,此时它堵塞了3个会话,其正在等待cacheid:0X10的ROWCACHE。
- Chain3:堵塞源是节点2,SID:6642的会话,此时它堵塞了11个会话,其正在等待cacheid:0X10的ROWCACHE。
从以上堵塞Chain我们可以看到堵塞源都在等待cacheid:0X10的ROWCACHE。其正在运行的SQL均为查询数据库基表或试图的SQL。
AWR分析
接下来,我们查看AWR:
- 发现被访问比较多的ROWCACHE是cacheid:0X10和cacheid:0X15。
- AWR显示,SQL运行大部分时间都花在解析上,sharedpoollatches上的活动会话占比很高。
综合以上情况,初步确定由于sharedpool空闲较少,应用SQL频次有增加,发现部分查询数据字典的SQL出现查询缓慢甚至查不出来的情况,会话积压导致内存不足,此时自动收集统计信息的JOB成为压死数据库的最后一根稻草。
解决方案
我们收集了数据字典的统计信息,将部分查询数据字典的SQL绑定了最优执行计划。并进行了sharedpool的大小调整,在原来的基础上增加了SGA预留的2G,并部署了sharedpool剩余空间的监控,少于500M告警。并要求应用侧整改SQL突增的问题。目前来看这些方式行之有效,到目前为止数据库再无发生过类似的故障。
原创文章,作者:小编小本本,如若转载,请注明出处:https://www.benjiyun.com/yunzhujiyunwei/vps-yunwei/5900.html
