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

1、DBLINK分布式事务失败又遭遇RAC热点块争用某天下午16点左右，该案例中的数据库出现严重性能故障，主要表现为大量业务SQL无法正常运行，同时订单表无法正常插入数据，严重影响业务的正常运行。最终通过重启数据库并开启一个节点运行后，恢复正常。故障分析以下是截取问题时段(16:00-17:00)crm2db两节点AWR报告部分信息：节点1上DB Time是Elapsed时间的211倍，说明节点1处于极其繁忙的状态。而节点2上DB Time/Elapsed时间更是达到了276倍，远远高于数据库可用CPU数128，同样说明节点2处于非常繁忙的状态。大量的会话都处于等待状态，大量的事务被挂起，数据库实

2、例处于不可用状态。 从TOP 5等待事件来看，节点1的等待事件为：节点2的等待事件为：两个节点等待基本一致，大量的gc及tx相关等待，同时平均等待时间均处于几百，上千甚至上万毫秒，这是数据库正常运行所无法忍受的。在11g中将gc buffer busy分为gc buffer busy acquire和gc buffer busy release，其中前者是当session1尝试请求访问远程实例buffer，但是在session1之前已经有相同实例上另外一个session2请求访问了相同的buffer，并且没有完成，那么session1需要等待gc buffer busy acquir

3、e。而后者是在session1之前已经有远程实例的session2请求访问了相同的buffer，并且没有完成，那么session1需要等待gc buffer busy release。这通常是由于同一数据在不同数据库实例上被请求访问，特别是在通过两个节点频繁执行并发插入导致。而本次故障我们通过分析相关性能数据，可以看到问题时段如下大量gc等待发生在insert order_list视图上(该视图对应的基表为customer_order订单表)。-此处省略大量类似输出同时从awr中同样可以看到问题时段gc争用最为严重的为订单表中的索引IDX_ORDER_LIST_OLNBR_1，该索引为右向增长

4、的数值索引，近一半的gc争用发生在该索引上。接下来对于TX等待中的enq:TX - allocate ITL entry事务槽分配的等待，该等待通常发生在DML并发操作频繁的对象，可以看到问题时段大量该等待同样发生在如下insert订单表上。-此处省略大量类似输出而针对问题时段出现的大量enq: TX contention等待，通过相关性能数据的分析，看到大量业务SQL被sid为1969的会话所阻塞，而1969号进程是oracle的RECO后台进程，简单说该进程负责处理失败的分布式事务。而如果分布式事务失败，在恢复处理过程中则会阻塞分布式事务中涉及表的查询及DML操作。可以看到如下问题时段大量

5、正常会话被RECO进程阻塞。-此处省略大量类似输出-此处省略大量类似输出同时，我们进一步从告警日志发现在7月2日下午开始，存在十几次由于远端数据库问题，导致分布式事务失败的告警信息，以下列举距离问题时段最近的一次告警信息如下：故障处理及总结针对分布式事务锁表的故障：(1)跨dblink分布式事务控制处理的数据量不要太大，尽量进行小事务封装并快速提交。(2)网络质量对于跨dblink的分布式事务非常关键，确保dblink之间的网络稳定性，需要对网络进行实时监控，以判断网络是否存在明显抖动现象。(3)当然通过应用改造，避免使用跨dblink的分布式事务为最佳选择，但需要对现有应用逻辑做适当修改，改

6、造后由于未使用分布式事务，即可规避分布式事务失败回退后锁表隐患，可能需要一定的应用变更停机时间。针对RAC节点间热点块的故障：(1)单节点进行数据库访问特别是insert操作,避免数据交叉访问。此种解决方案可以最大限度避免两节点间gc等待，规避RAC两节点之间跨实例的数据块争抢的开销，但需要应用程序做一定改造。(2)如无法进行应用改造，可以针对热点表改造为hash或range hash方式分区表并针对具有右向增长性质的字段创建local索引，该种解决方案对应用透明，将热点表及索引使用hash算法将数据分散在多个段中，缓解热点块争用，其目的就是打散这些集中访问的数据块，减少数据块被多数会话同时访问的频率，从而分散热点块的争用。但需要关注被改造表涉及的SQL执行计划，确保相关SQL执行效率。(3)如无法进行分区表改造，至少需要对热点表中具有右向增长性质的索引，如主键、日期类型及数值自增长类型字