概述

最近在监控发现某个数据库发生一个等待事件：enq: TX - index contention，报错截图如下：

处理还是比较简单的，这里主要说一下enq: TX - index contention这个等待事件。

enq: TX - index contention

enq:TX-index contention是一个非常常见的等待事件，其专指由于索引分裂产生的竞争等待。最常见的索引竞争一般发生在主键索引上，主键值从序列（sequence)中获取，每个事务都会生成一条新的记录，每条记录都要获得一个新的序列号，因为从sequence中取出的值是单向递增的，当索引中插入数据，并且维护索引结构的时候，不得不一直走向索引的最右侧的分支，对于每一个操作，都会想要维护索引中最右边的叶节点，那么所有的操作都会关注同一个内存块，希望能够维护这块内存，这就是一种典型的竞争形式。但在同一时间，只有一个人能够修改这块内存，因此当有一个人在修改的时候，其他所有想修改的人只能处于等待状态。

当运行 OLTP 系统时，当应用程序并发很高时，可能会看到与表相关的索引上的高 TX 队列争用。这通常发生在应用程序同时并发执行大量 INSERT 和 DELETE 时。 对于 RAC 系统，并发的 INSERT 和 DELETE 可能发生在所有的实例中。

原因是在将新行插入索引时，索引块会分裂。操作将不得不等待模式4的 TX 锁，直到进行索引分裂的会话完成操作。当在索引块中找不到需要插入新行的空间时，会话将启动索引分裂。开始分裂之前，它将清除块中的所有键，以检查在被删除的块中是否有足够的空间。

分裂操作必须做以下活动：

1. 分配一个新的块。
2. 将一定百分比的行复制到新索引块。
3. 将新索引块添加到索引结构并提交操作。

在 RAC 环境中，由于包括全局缓存操作，这可能是一项昂贵的操作。如果分裂发生在分支或根块级别，则影响将更大。

原因

这里最可能的原因是：

• 从应用程序大量访问的表的索引。
• 单向生长的表列索引。也就是说，大多数索引插入仅在索引的右边缘出现。
• 已执行大量数据清除，并紧接着又发生了高并发插入。

解决方案

先看下网上提供的几个解决方案，如下：

1、将 AWR 报告的'Segments by Row Lock Waits'中列出的索引重建为反向键索引或散列分区

例如：

CREATE INDEX <index name> ON <column> REVERSE;

说明：反向键索引旨在消除插入应用程序上的索引热点。 这些指标非常适合插入操作的性能。 但它的缺点是它可能影响索引范围扫描的性能。

在多用户 OLTP 环境中，如果索引中的少量叶子索引块并发很高，那么哈希分区方法可以提高索引的性能。 在某些 OLTP 应用程序中，索引插入只发生在索引的右边缘。 当索引定义为单调递增的列时，可能会发生这种情况。 在这种情况下，由于索引页，缓冲区，更新锁存器和附加索引维护活动的争用，索引的右边缘成为热点，从而导致性能下降。

建议在将索引重新构建为反向键索引或哈希分区后，测试应用程序的性能。

2、考虑增加 sequence 的 CACHE 大小

alter sequence <owner>.<seq name> cache <required value>;

当我们使用单调增加的 sequence 来填充列值时，具有高序列值的叶子索引块将随着每个插入而改变，这使得它成为块分裂的热块和潜在候选。

使用 CACHE SIZE（并且可能使用 NOORDER 选项），每个实例将使用具有不同范围的 sequence，减少索引键插入同一组叶子索引块。

3、在大量数据清除后，重建或 shrink 相关联索引

如果有大量的数据清除（删除）操作，通过 alter index rebuild 或 alter index shrink 命令重建或缩小关联的索引有助于减少等待。

4、增加索引的 PCT_FREE

高的 PCT_FREE 有助于避免索引块的 ITL 争用。当一个区块内的所有可用 ITL 当前正在使用中，而且 Oracle 的 PCT_FREE 区域没有足够的空间来动态分配新的 ITL 插槽，那么将发生 ITL 争用。

清理无效索引

最终选择的解决方案是调整索引，避免对少量块进行大量访问。

--当前索引执行情况
SELECT p.object_name, p.operation, p.options, COUNT(1)
FROM v$sql_plan p, v$sql s
WHERE p.object_owner <> 'SYS'
 AND p.OBJECT_NAME in
 (select index_name
 from dba_indexes
 where table_name = 'S_SHIP_UNIT_LINE')
 AND p.sql_id = s.sql_id
GROUP BY p.object_name, p.operation, p.options
ORDER BY 1, 2, 3;
--历史索引执行情况
SELECT p.object_name, p.operation, p.options, COUNT(1)
FROM dba_hist_sql_plan p, dba_hist_sqlstat s
WHERE p.object_owner <> 'SYS'
 AND p.object_name in
 (select index_name
 from dba_indexes
 where table_name = 'S_SHIP_UNIT_LINE')
 AND p.sql_id = s.sql_id
GROUP BY p.object_name, p.operation, p.options
ORDER BY 1, 2, 3;

调整索引后问题解决。

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下！