暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

案例分享-enq:SS导致的系统HANG死

白鳝的洞穴 2020-04-07
2256
某日凌晨凌晨,某银行的核心系统变慢,出现大量交易超时,值班DBA从V$SESSION_WAITS里看到大量enq:SS等待,从AWR报告上看:


存在大量SS锁等待,SS锁的含义是SORT SEGMENTS,是排序操作引起的临时表空间临时段使用引起的等待,这个等待事件一般不会很严重。通过HANGANALYZE可以看到以下情况:

==============

HANG ANALYSIS:

==============

Found 38 objectswaiting for <cnode/sid/sess_srno/proc_ptr/ospid/wait_event>

    <0/954/31806/0xfcf8918/336766/enq: SS -contention>

Found 14 objectswaiting for <cnode/sid/sess_srno/proc_ptr/ospid/wait_event>

    <0/916/48094/0xfcf59d8/1089592/enq: TS -contention>

Open chains found:

Chain 1 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/1120/1/0xfca9d18/241784/smontimer>

 -- <0/916/48094/0xfcf59d8/1089592/enq: TS -contention>

 -- <0/954/31806/0xfcf8918/336766/enq: SS -contention>

 -- <0/837/19145/0xfcf0b18/1049132/enq: TX -row lock contention>

Other chains found:

Chain 2 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/857/36350/0xfd0d3d8/1245462/enq: SS -contention>

Chain 3 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/894/5267/0xfd0e398/1294580/NoWait>

Chain 4 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/944/34804/0xfcd5218/213148/NoWait>

Chain 5 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/963/52342/0xfcc5df8/1458726/StreamsAQ: qmn slave idle wait>

Chain 6 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/1073/32685/0xfcf12f8/1208690/StreamsAQ: qmn slave idle wait>

Chain 7 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/1088/62452/0xfcbd038/1368826/NoWait>

Chain 8 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/1102/3/0xfcb71b8/270588/Streams AQ:qmn coordinator idle>

Chain 9 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/1114/7/0xfcac478/148042/Streams AQ:waiting for time man>

 

现场DBA根据HANGANALYZE的情况杀掉了阻塞者,不过很快又一个新的阻塞者产生了,系统并未恢复正常。为了尽快恢复应用,在远程三线专家的建议下,决定重启实例,重启实例后,恢复正常。根据银行的规定,需要对本次故障进行全面分析。
本次故障主要特点是有一个会话持有ts锁(TS锁是临时表空间、临时段相关的锁):

Found 14 objects waiting for<cnode/sid/sess_srno/proc_ptr/ospid/wait_event>

<0/916/48094/0xfcf59d8/1089592/enq:TS - contention>

另外有大量的会话在等待SS锁:

Found 38 objectswaiting for <cnode/sid/sess_srno/proc_ptr/ospid/wait_event>

    <0/954/31806/0xfcf8918/336766/enq: SS -contention>

其余的等待很少,说明系统基本上处于HANG的状态,HANG的原因是由于都在等待TS锁和SS锁。

因此可以判断SMON进程的故障可能导致类似问题,比如SMON过于繁忙(正在做恢复)。通过和现场应用运维人员沟通,在问题发生前确实杀过进程,不过目前所有的事务都已经回滚完成。基本可以排除SMON过忙无法授权SS锁导致了SS锁等待的问题。从HANGANALYZE的数据也可以验证这一点:

Chain 1 :<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :

    <0/1120/1/0xfca9d18/241784/smontimer>

 -- <0/916/48094/0xfcf59d8/1089592/enq: TS -contention>

 -- <0/954/31806/0xfcf8918/336766/enq: SS -contention>

 -- <0/837/19145/0xfcf0b18/1049132/enq: TX -row lock contention>

 

Smon进程在等待smon timer,说明smon是处于idle状态的。

经过上述分析,该现象和BUG9902939类似,该BUG的主要特征为:

l 存在大量会话等待enq:SS

l 存在大量会话等待enq:TS

l 一个空闲的SMON进程持有TS锁

l 杀掉持有TS锁的阻塞会话,会产生一个新的会话,继续持有该TS锁,因此TS锁无法解锁

l 重启实例可以恢复正常

l 该BUG目前在10.2.0.4(含)以下版本中存在

  事后,根据当前情况,该核心数据库在运维窗口打了补丁,此后该问题未再重现。




最后修改时间:2020-04-08 09:22:49
文章转载自 白鳝的洞穴,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论