一次enq:TX-index contention故障分析

版权声明:本文为Buddy Yuan原创文章,转载请注明出处。原文地址:一次enq:TX-index contention故障分析
这个故障是头一天晚上9点多开始,客户发现索引enq:TX-index contention分裂很严重,系统程序插入的时候有大量的enq:TX-index contention等待,同是伴随着还有gc方面的等待。在12点多的时候,重建了索引最后恢复了。现在需要我们分析根本原因。

首先通过当天晚上10点多的AWR报告可以发现,enq:TX-index contention分裂很严重,两个节点之间的网络延迟非常严重。


 

 

通过对比正常时间段和异常时间段的leaf node splits,发现每秒种索引分裂的个数并没有异常增长,也就侧面说明业务量没有增长。

 

 

我们做个相关插入sql语句的sqlhc报告,发现引起索引争用的语句。执行的频次没有发现很大的增长。

 

 
通过分析,我们可以认定这个插入SQL是被影响的。那么究竟是被什么影响的呢?

 
通过分析7天的awr情况发现在5月20日从早上11点开始,数据库CPU就一直增长,到下午18点已经达到了80%,最终一直涨到100%。继续查询AWR报告,发现占用CPU高的语句就一条。占比达到95%。

 
对该语句做SQLHC报告,发现该语句的执行计划并没变,执行次数也没有明显的差异,但是逻辑读在问题期间大幅增长了。从而导致执行语句需要更多的cpu。

 

 

 
分析该语句的执行计划,可以发现,走了全表扫描。而它使用的谓词条件上正好有索引,优化器可以使用索引INX_OWN_O_I_REQ_ORDER_NO,但是没有使用,通过查看报告,发现索引的order_no上缺乏列的统计信息。

 
此时处理的办法有两种,一种是对表进行统计信息收集,在收集的时候可以选择,method_opt=> ‘for all indexed columns’。第二种方法就是对SQL语句进行绑定。客户选择了第二种方式,我们将SQL绑定之后,系统消耗的cpu逐步降低,上面那条插入语句瞬间就好了很多,客户反映插入速度变快了。最终这个问题被定义为CPU资源繁忙导致网络软中断,引起了gc,最终导致enq:TX-index contention争用严重的问题。

分享到: 更多

Post a Comment

Your email is never published nor shared. Required fields are marked *