问题描述:
从EM里面看到Concurrency等待的活动回话数比较高,系统有hang死风险
问题分析:
检查了Oracle数据库的告警日志无任何错误。
查看ash报告:
Top User Events
Event |
Event Class
% Activity
Avg Active Sessions
cursor: pin S wait on X
Concurrency
92.42
13.88
CPU + Wait for CPU
CPU
2.53
0.38
inactive session
Other
2.17
0.33
SQL Id |
SQL Text
select vin into :b0 from v_cardepot_doc where jjdh=:b1
分析:发现大量cursor: pin S wait on X等待产生,而等待是sql为select vin into :b0 from v_cardepot_doc where jjdh=:b1。
为了查清楚等待事件产生的原因,使用oracle oradebug hanganalyze工具分析如下:
Chain 1 : :
<1/88/23640/0x2e3179e8/905404/Streams AQ: qmn slave idle wait>
Chain 2 : :
<1/94/2283/0x2e3142c8/479260/cursor: pin S wait on X>
Chain 3 : :
<1/95/3246/0x2e319188/762088/No Wait>
Chain 4 : :
<1/97/377/0x2e310ba8/901216/cursor: pin S wait on X>
Chain 5 : :
<1/98/2980/0x2e315288/827636/cursor: pin S wait on X>
Chain 6 : :
<1/100/50945/0x2e30bce8/487534/cursor: pin S wait on X>
Chain 7 : :
<1/101/23319/0x2e30d488/892972/cursor: pin S wait on X>
Chain 8 : :
<1/103/4990/0x2e3046c8/856140/cursor: pin S wait on X>
Chain 9 : :
<1/105/35394/0x2e30e448/680074/cursor: pin S wait on X>
Chain 10 : :
<1/106/14845/0x2e30fbe8/860208/cursor: pin S wait on X>
分析:从dump结果看,大量的等待事件并没有被进程所阻塞。所以判断直接杀掉这些进程此故障就解决了。
解决办法:
分析后,判断可能是由于网络或者其他原因导致客户端进程到服务器连接闪断,造成session hang死情况,由于oracle的清理资源策略的缘故,所以导致大量死掉的session挂在系统上,而消耗大量的资源。
找应用确认后,发现一台通过dblink连接查询的一台db死掉了,可见最初的分析是正确的。
综述:直接杀掉所有客户端的进程
ps –ef|grep ora|grep LOCAL=NO|awk ‘{print $2}’|xargs kill -9
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/11088128/viewspace-706650/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/11088128/viewspace-706650/