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

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

出现了平时少见的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那一块的问题：

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

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

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

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

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