查看原文
其他

DBLINK分布式事务失败又遭遇RAC热点块争用

2016-10-26 Oracle

编辑手记:在DBLINK中由于远端数据库无法正常执行分布式事务,又遭遇RAC热块争用,两者共同作用导致数据库严重故障。接下来我们从AWR报告分析入手,一步步分析并解决问题。


故障现象

某天下午16点左右,该案例中的数据库出现严重性能故障,主要表现为大量业务SQL无法正常运行,同时订单表无法正常插入数据,严重影响业务的正常运行。最终通过重启数据库并开启一个节点运行后,恢复正常。


故障分析

以下是截取问题时段(16:00-17:00)crm2db两节点AWR报告部分信息:



节点1上DB Time是Elapsed时间的211倍,说明节点1处于极其繁忙的状态。



而节点2上DB Time/Elapsed时间更是达到了276倍,远远高于数据库可用CPU数128,同样说明节点2处于非常繁忙的状态。大量的会话都处于等待状态,大量的事务被挂起,数据库实例处于不可用状态。

 

从TOP 5等待事件来看,节点1的等待事件为:



节点2的等待事件为:



两个节点等待基本一致,大量的gc及tx相关等待,同时平均等待时间均处于几百,上千甚至上万毫秒,这是数据库正常运行所无法忍受的。


在11g中将gc buffer busy分为gc buffer busy acquiregc buffer busy release,其中前者是当session1尝试请求访问远程实例buffer,但是在session1之前已经有相同实例上另外一个session2请求访问了相同的buffer,并且没有完成,那么session1需要等待gc buffer busy acquire。而后者是在session1之前已经有远程实例的session2请求访问了相同的buffer,并且没有完成,那么session1需要等待gc buffer busy release。这通常是由于同一数据在不同数据库实例上被请求访问,特别是在通过两个节点频繁执行并发插入导致。


而本次故障我们通过分析相关性能数据,可以看到问题时段如下大量gc等待发生在insert order_list视图上(该视图对应的基表为customer_order订单表)。


---此处省略大量类似输出


同时从awr中同样可以看到问题时段gc争用最为严重的为订单表中的索引IDX_ORDER_LIST_OLNBR_1,该索引为右向增长的数值索引,近一半的gc争用发生在该索引上。



接下来对于TX等待中的enq:TX - allocate ITL entry事务槽分配的等待,该等待通常发生在DML并发操作频繁的对象,可以看到问题时段大量该等待同样发生在如下insert订单表上。



---此处省略大量类似输出


而针对问题时段出现的大量enq: TX –contention等待,通过相关性能数据的分析,看到大量业务SQL被sid为1969的会话所阻塞,而1969号进程是oracle的RECO后台进程,简单说该进程负责处理失败的分布式事务。而如果分布式事务失败,在恢复处理过程中则会阻塞分布式事务中涉及表的查询及DML操作。可以看到如下问题时段大量正常会话被RECO进程阻塞。



---此处省略大量类似输出


---此处省略大量类似输出


同时,我们进一步从告警日志发现在7月2日下午开始,存在十几次由于远端数据库问题,导致分布式事务失败的告警信息,以下列举距离问题时段最近的一次告警信息如下:



故障处理及总结

针对分布式事务锁表的故障:

(1)跨dblink分布式事务控制处理的数据量不要太大,尽量进行小事务封装并快速提交

(2)网络质量对于跨dblink的分布式事务非常关键,确保dblink之间的网络稳定性,需要对网络进行实时监控,以判断网络是否存在明显抖动现象。

(3)当然通过应用改造,避免使用跨dblink的分布式事务为最佳选择,但需要对现有应用逻辑做适当修改,改造后由于未使用分布式事务,即可规避分布式事务失败回退后锁表隐患,可能需要一定的应用变更停机时间。


针对RAC节点间热点块的故障:

(1)单节点进行数据库访问特别是insert操作,避免数据交叉访问。此种解决方案可以最大限度避免两节点间gc等待,规避RAC两节点之间跨实例的数据块争抢的开销,但需要应用程序做一定改造。

(2)如无法进行应用改造,可以针对热点表改造为hash或range hash方式分区表并针对具有右向增长性质的字段创建local索引,该种解决方案对应用透明,将热点表及索引使用hash算法将数据分散在多个段中,缓解热点块争用,其目的就是打散这些集中访问的数据块,减少数据块被多数会话同时访问的频率,从而分散热点块的争用。但需要关注被改造表涉及的SQL执行计划,确保相关SQL执行效率。

(3)如无法进行分区表改造,至少需要对热点表中具有右向增长性质的索引,如主键、日期类型及数值自增长类型字段通过hash方式创建全局分区索引,缓解热点块争用,同理,其目的也是打散这些集中访问的数据块,特别是右向增长的索引热点永远在最右端。此种解决方案同样对应用透明,同时改动最小,仅需要对相关索引进行重建。


如何加入"云和恩墨大讲堂"微信群

搜索 盖国强(Eygle)微信号:eyygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。


近期文章

Oracle 11g Data Guard环境中的归档管理

一则library cache lock问题处理 

一则强行关库引发的蝴蝶效应

深入学习:In Memory Undo 

一则因内存导致的集群故障

巧妙kill CRS进程而不导致主机重启

insert into 太慢的问题

资源下载

关注本微信(OraNews)回复关键字获取

2016DTCC, 2016数据库大会PPT;

DBALife,"DBA的一天"精品海报大图;

12cArch,“Oracle 12c体系结构”精品海报;

DBA01,《Oracle DBA手记》第一本下载;

YunHe“云和恩墨大讲堂”案例文档下载;



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存