Oracle索引分裂把核心库干挂了，我麻了...

1.故障现象

某核心库出现大量了enq: TX - index contention导致的索引分裂，期间也发现大量log file sync异常等待事件，怀疑链路抖动以及IO有异常情况。

2.分析过程

通过对AWR报告分析发现出现了大量enq: TX - index contention、log file sync异常的等待事件。

继续跟踪ASH报告分析到等待事件的阻塞源session。

2.1 log file sync

什么是log file sync？

当用户会话提交时，该会话事务生成的所有重做记录都需要从内存中刷新到重做日志文件中，以确保该事务对数据库所做的更改是永久性的。

1)分析IO性能问题：比较'log file sync'和'log file parallel write'的平均等待时间。

log file sync的等待为31毫秒，IO有延迟，怀疑链路抖动以及IO有异常情况。

2)分析程序提交：比较 user commit/rollback 同 user calls 比值的平均值确认提交是否异常。

user calls/(user commits+user rollbacks) 本次平均值为180.52= 180.52/(1+0) ，平均每180.52次 user calls 就会有一次 commit，提交不是很频繁。

3）确认LGWR switch是否异常

推荐值是每15-20分钟切换一次，也就是每小时切换3-4次，日志切换正常。

4）排查数据库参数

_use_adaptive_log_file_sync是 Oracle 数据库的一个隐含参数，它控制着名为“自适应日志文件同步”的核心机制。这个机制直接影响数据库在执行提交（COMMIT）操作时的性能和行为。建议在繁忙的 OLTP 系统上将此参数设置为 FALSE，强制使用响应更快的 POST/WAIT模式，此处参数设置正常。

2.2 TX - index contention

什么是enq: TX - index contention索引分裂？

session向一个索引块中执行插入/更新时产生了索引块的split，而其他的session也要往该索引块中插入数据，此时，其他session必须要等待split完成，由此引发了该等待事件。

如上图当有新值插入到L4叶节点块的时候，此时L4叶节点块是“充满”状态，已经没有足够的空间来存储新值了，此时会在B2分支节点下，分裂出一个新的叶节点L5来存储新值。

1）等待事件分析

Wait Event Histogram Detail中大于1/8s的等待占比达到19.6%。

找到产生争用的索引对象，确定该索引为单列索引.

3.根本原因

由于索引分裂，出现阻塞导致导致会话等待，故系统响应缓慢，同时大量log file sync异常等待事件，同时链路抖动以及IO有异常情况。

高并发UPDATE场景下，系统CPU资源紧张或I/O延迟高会延长单个索引分裂操作的时间，从而加剧其他会话的等待。

4.永久措施

持续监控IO，业务低峰期对于热快竞争的索引重建减少碎片，如果后续再重复发生，评估调整热快索引的PCTFREE：适当增加索引的 PCTFREE，可以为索引块内的更新预留更多空间，减少因空间不足导致的分裂概率。

更多解决索引分裂的方法如下：

更多内容关注视频号

👇👇👇👇