文档内容

适用于:

目标

本文档的目的是帮助诊断" enq: TX - index contention"问题

解决方案

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

原因是在将新行插入索引时，索引块会分裂。操作将不得不等待模式4的 TX 锁，直到进行索引分裂的会话完成操作。

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

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

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

原因：

最可能的原因是：

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

识别热索引：

有争用的索引可以从问题时段的 AWR 报告中确定。

而这些对象可以从 V$SEGMENT_STATISTICS 或从 AWR 报告中的“Segments by Row Lock Waits”或“Segments by ITL Waits”或“Service ITL Waits”中找到。
 

解决方案：

这里的解决方案是调整索引，避免对少量块进行大量访问。

以下是我们可以尝试的选项：

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

例如：

从性能调优指南 - 

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

http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/design.htm#sthref112

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

http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/data_acc.htm#i2678

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

• 考虑增加 sequence 的 CACHE 大小

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

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

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

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

• 增加索引的 PCT_FREE

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

参考