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 条评论
登录 后参与评论

相关文章

来自专栏即时通讯技术

微信自用高性能通用key-value组件MMKV已开源!

腾讯微信团队于2018年9月底宣布开源 MMKV ,这是基于 mmap 内存映射的 key-value 组件,底层序列化/反序列化使用 protobuf 实现,...

1202
来自专栏数据和云

青铜到王者,看看你的MySQL数据库是什么段位,如何提升?

作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

1564
来自专栏架构师之路

mysql并行复制降低主从同步延时的思路与启示

一、缘起 mysql主从复制,读写分离是互联网用的非常多的mysql架构,主从复制最令人诟病的地方就是,在数据量较大并发量较大的场景下,主从延时会比较严重。 为...

3577
来自专栏文渊之博

参数化(三):参数嗅探

    在之前的随笔中我提到过参数嗅探,这是非常重要的概念。下面我们深入的研究一下参数嗅探…     首先我们知道批处理可以是参数化的或者非参数化。参数化的批处...

1747
来自专栏IT大咖说

开源NewSQL – CockroachDB在百度内部的应用与实践

2662
来自专栏玄魂工作室

嗅探、中间人sql注入、反编译--例说桌面软件安全性问题

今天这篇文章不准备讲太多理论,讲我最近遇到的一个案例。从技术上讲,这个例子没什么高深的,还有一点狗屎运的成分,但是它又足够典型,典型到我可以讲出很多大道理用来装...

3395
来自专栏ThoughtWorks

phantomJs之殇,chrome-headless之生 | 洞见

技术雷达快讯:自2017年中以来,Chrome用户可以选择以headless模式运行浏览器。此功能非常适合运行前端浏览器测试,而无需在屏幕上显示操作过程。在此之...

3706
来自专栏沃趣科技

Oracle压缩黑科技(一)—基础表压缩

原文链接 https://www.red-gate.com/simple-talk/sql/oracle/compression-oracle-basic-ta...

2738
来自专栏IT技术精选文摘

ElasticSearch详解与优化设计

1、简介 ElasticSearch(简称ES)是一个分布式、Restful的搜索及分析服务器,设计用于分布式计算;能够达到实时搜索,稳定,可靠,快速。和Apa...

3925
来自专栏大数据

如何查询InfluxDB

InfluxDB是一个很流行的基于时间序列的数据库,下面是这个数据库的最基本的查询命令。InfluxDB使用类SQL(实际上它就是一种特殊的“SQL”)的语言。

2.2K10

扫码关注云+社区