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

编辑手记:在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方式创建全局分区索引,缓解热点块争用,同理,其目的也是打散这些集中访问的数据块,特别是右向增长的索引热点永远在最右端。此种解决方案同样对应用透明,同时改动最小,仅需要对相关索引进行重建。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-10-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Netkiller

压力测试中存在的问题

压力测试中存在的问题 (What) 什么是压力测试 软件压力测试是一种基本的质量保证行为,它是每个重要软件测试工作的一部分。软件压力测试的基本思路很简单: 不是...

3084
来自专栏北京马哥教育

Web APP编程模型和IO策略

现代大型高性能网站诸如淘宝,京东,微博,FB,知乎等等,网站架构涉及很多知识。像业务分层,软件分割模块化,分布式部署,集群服务器,负载均衡等技术可以帮助架构师将...

3367
来自专栏Linyb极客之路

低延迟系统的最佳实践

低延迟意味着更快的响应时间,更快的性能,以下最佳实践大部分来自于Quora等问题提炼:

692
来自专栏北京马哥教育

【大咖讲堂178期】 | Zabbix与Python不得不说的基情

分享提要 在平时的工作...

3809
来自专栏battcn

没有Eureka,但多了Nacos

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您实现动态服务发现、服务配置管理、服务及流量管理。

622
来自专栏恰同学骚年

《大型网站技术架构》读书笔记四:瞬时响应之网站的高性能架构

此篇已收录至《大型网站技术架构》读书笔记系列目录贴,点击访问该目录可获取更多内容。

632
来自专栏程序员的SOD蜜

“批量少次”还是“少量多次”--邮件通信系统效率浅谈

 在做Web开发的时候,相信很多人都看过一个“批量少次”原则:     Web服务器采用HTTP协议,它是一个非持久连接的协议,是无状态的(虽然可以采用多种...

1905
来自专栏企鹅号快讯

Python爬虫实战:爬取全站小说排行榜

喜欢看小说的骚年们都知道,总是有一些小说让人耳目一新,不管是仙侠还是玄幻,前面更了几十章就成功圈了一大波粉丝,成功攀上飙升榜,热门榜等各种榜,扔几个栗子出来: ...

30210
来自专栏数据和云

Real World Performance 经典性能优化案例-索引竞争

编辑手记:Real World Performance(RWP)团队是个天才的性能优化团队,不断的寻找和创造新的方法分析诊断当今世界业务系统的性能。在他们眼里,...

3459
来自专栏架构师小秘圈

设计和实现一款轻量级的爬虫框架

作者:王爵nice ,来自架构文摘(ID:ArchDigest) 说起爬虫,大家能够想起 Python 里赫赫有名的 Scrapy 框架, 在本文中我们参考这...

2845

扫码关注云+社区