Oracle enq: DX - contention 一次问题分析过程


      客户反应晚上跑批异常,有一步平时20秒左右结束,昨晚跑了3000多秒,发来awr报告让我分析。很是兴奋,双击打开直奔TOP 5等待事件,如下:


Oracle enq: DX - contention 一次问题分析过程_第1张图片

出现了平时少见的enq: DX - contention 和inactive transaction branch。这两个事件是相伴的。 这两个等待事件是和DBLINK相关的,metalink上有相关的文章:High CPU by Sessions Holding DX Enqueue; Others Waiting 'enq: DX - contention' [ID 1275884.1]

 

大意就是执行dblink语句时候,由于人为取消终止或网络等问题导致语句触发上面的等待事件,便一直卡在那里。我这边的情况比较奇怪,是个存储过程,只要一执行,就会触发该等待事件,导致执行不下去。该存储过程带有两个in参数,使用绑定变量的形式传参就会触发该事件,若是将参数用动态拼接则很快执行过去。。。不得其解。


本以为昨晚跑批延时的问题是由于该等待事件导致,结果发现这个等待事件已经存在一个多星期了,而前几天的跑批没有任何问题,说明虽然awr中DX等待事件很高,但并不是这个导致跑批异常的原因。。


没办法,只好分析TOP SQL那一块的问题:


Oracle enq: DX - contention 一次问题分析过程_第2张图片

出问题那一步就是存储过程:f2mw3dp1z3nx1  正常每次执行20几秒。。但从sql执行时间长短角度看不出说明问题,只好一步步看存储过程中的内容。。发现这条sql:atqht9zp3j1ym  属于该存储过程。。一下子看到了胜利的希望。。

之前也有看到atqht9zp3j1ym 这条sql,但是发现该sql平均每次执行时间接近0秒,就没继续考虑。。。现在既然存储过程中有该sql,而该sql总时间也达到了2600多秒,说明在执行次数上存在问题了。。。


找业务人员,询问该sql执行次数是否正常。。。业务人员先是一再强调每天都一样。。一样。。。接着开始怀疑。。于是查看以前每月的这两天。。发现也出现跑批时间变长的情况。。。


接下来就该业务人员恍然大悟了,在每个月这两天,由于业务上的特殊情况,导致该sql的执行次数达到200多万次,从而导致整个跑批时间延长。。。。


总结: 不要想当然的认为TOP 5等待事件就一定是问题的原因所在,真相很可能被TOP 5等待事件掩饰了。问题发生在哪里,就要一步步定位,不要嫌麻烦,也不要吝啬怀疑,大胆揣测,小心验证,然后多总结。。。嘿嘿。。

你可能感兴趣的:(oracle,dx)