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

相关文章

来自专栏Golang语言社区

Golang协程与通道整理

协程goroutine 不由OS调度,而是用户层自行释放CPU,从而在执行体之间切换。Go在底层进行协助实现 涉及系统调用的地方由Go标准库...

2487
来自专栏Golang语言社区

Golang协程与通道整理

协程goroutine 不由OS调度,而是用户层自行释放CPU,从而在执行体之间切换。Go在底层进行协助实现 涉及系统调用的地方由Go标准库...

3467
来自专栏CodingToDie

分布式事务解决方案

Spring Cloud 分布式事务管理 在微服务如火如荼的情况下,越来越多的项目开始尝试改造成微服务架构,微服务即带来了项目开发的方便性,又提高了运维难度以及...

3694
来自专栏小狼的世界

[每天五分钟,备战架构师-10]数据库系统

事务是数据库系统运行的基本工作单位,相当于操作系统中的进程,事务具有ACID特性。从用户的角度来看,事务中的操作要么都做,要么都不做。

92
来自专栏Linyb极客之路

性能测试之压测中TPS上不去的几种原因分析

在压力测试中,有时候要模拟大量的用户请求,如果单位时间内传递的数据包过大,超过了带宽的传输能力,那么就会造成网络资源竞争,间接导致服务端接收到的请求数达不到服务...

1255
来自专栏Spark学习技巧

为什么分布式一定要有Redis?

考虑到绝大部分写业务的程序员,在实际开发中使用 Redis 的时候,只会 Set Value 和 Get Value 两个操作,对 Redis 整体缺乏一个认知...

382
来自专栏腾讯大数据的专栏

分布式高可靠消息中间件-Hippo

前言 随着大数据产品的日渐丰富以及数据应用场景需求的增加,TDBank作为腾讯大数据平台的数据接入环节的位置也越发显得重要(见下图)。截止目前为止TDBank...

2196
来自专栏美团技术团队

【技术博客】Cache应用中的服务过载案例研究

简单地说,过载是外部请求对系统的访问量突然激增,造成请求堆积,服务不可用,最终导致系统崩溃。本文主要分析引入Cache可能造成的服务过载,并讨论相关的预防、恢复...

2905
来自专栏架构师之路

工作线程数究竟要设置为多少 | 架构师之路

一、需求缘起 Web-Server通常有个配置,最大工作线程数,后端服务一般也有个配置,工作线程池的线程数量,这个线程数的配置不同的业务架构师有不同的经验值,...

3698
来自专栏无题

在高并发的核心技术中如何实现幂等性

* 实际系统中有很多操作,是不管做多少次,都应该产生一样的效果或返回一样的结果。 例如: 前端重复提交选中的数据,应该后台只产生对应这个数据的一个反应结果。 ...

49411

扫描关注云+社区