文檔內容
目標
解決方案
參考
適用於:
Oracle Database - Enterprise Edition - 版本 10.2.0.1 到 11.2.0.4 [發行版 10.2 到 11.2]
本文檔所含信息適用於所有平臺
目標
本文檔的目的是幫助診斷" enq: TX - index contention"問題
解決方案`
當運行 OLTP 系統時，當應用程序併發很高時，可能會看到與表相關的索引上的高 TX 隊列爭用。這通常發生在應用程序同時併發執行大量 INSERT 和 DELETE 時。 對於 RAC 系統，併發的 INSERT 和 DELETE 可能發生在所有的實例中。
原因是在將新行插入索引時，索引塊會分裂。操作將不得不等待模式4的 TX 鎖，直到進行索引分裂的會話完成操作。
當在索引塊中找不到需要插入新行的空間時，會話將啓動索引分裂。開始分裂之前，它將清除塊中的所有鍵，以檢查在被刪除的塊中是否有足夠的空間。
分裂操作必須做以下活動：
o 分配一個新的塊。
o 將一定百分比的行復制到新索引塊。
o 將新索引塊添加到索引結構並提交操作。在 RAC 環境中，由於包括全局緩存操作，這可能是一項昂貴的操作。如果分裂發生在分支或根塊級別，則影響將更大。
原因：
最可能的原因是：
o 從應用程序大量訪問的表的索引。
o 單向生長的表列索引。也就是說，大多數索引插入僅在索引的右邊緣出現。
o 已執行大量數據清除，並緊接着又發生了高併發插入。
識別熱索引：
有爭用的索引可以從問題時段的 AWR 報告中確定。
Top 5 Timed Events:
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
en: TX - index contention 89,350 40,991 459 63.3 Concurrency
db file sequential read 1,458,288 12,562 9 19.4 User I/O
CPU time 5,352 8.3
Instance Activity Stats:
Statistic Total per Second per Trans
branch node splits 945 0.26 0.00
leaf node 90-10 splits 1,670 0.46 0.00
leaf node splits 35,603 9.85 0.05 而這些對象可以從 V$SEGMENT_STATISTICS 或從 AWR 報告中的“Segments by Row Lock Waits”或“Segments by ITL Waits”或“Service ITL Waits”中找到。
Segments by Row Lock Waits:
Owner Tablespace Object Name Obj.Type Row Lock Waits % of Capture
ACSSPROD ACSS_IDX03 ACSS_ORDER_HEADER_PK INDEX 3,425 43.62
ACSSPROD ACSS_IDX03 ACSS_ORDER_HEADER_ST INDEX 883 11.25
ACSSPROD ACSS_IDX03 ACSS_ORDER_HEADER_DT INDEX 682 8.69
Segments by ITL Waits
Owner Tablespace Name Object Name Subobject Name Obj. Type ITL Waits % of Capture
ACSSPROD ACSS_IDX03 ACSS_ORDER_HEADER_PK INDEX 6 50.00
ACSSPROD ACSS_IDX03 ACSS_ORDER_HEADER_ST INDEX 3 25.00
ACSSPROD ACSS_IDX03 ACSS_ORDER_HEADER_DT INDEX 3 25.00
解決方案：
這裏的解決方案是調整索引，避免對少量塊進行大量訪問。
以下是我們可以嘗試的選項：
• 將 AWR 報告的'Segments by Row Lock Waits'中列出的索引重建爲反向鍵索引或散列分區
例如：
CREATE INDEX <index name> ON <column> REVERSE;
從性能調優指南 -
反向鍵索引旨在消除插入應用程序上的索引熱點。 這些指標非常適合插入操作的性能。 但它的缺點是它可能影響索引範圍掃描的性能。
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 大小
alter sequence <owner>.<seq name> cache <required value>;
當我們使用單調增加的 sequence 來填充列值時，具有高序列值的葉子索引塊將隨着每個插入而改變，這使得它成爲塊分裂的熱塊和潛在候選。
使用 CACHE SIZE（並且可能使用 NOORDER 選項），每個實例將使用具有不同範圍的 sequence，減少索引鍵插入同一組葉子索引塊。
• 在大量數據清除後，重建或 shrink 相關聯索引
如果有大量的數據清除（刪除）操作，通過 alter index rebuild 或 alter index shrink 命令重建或縮小關聯的索引有助於減少等待。
• 增加索引的 PCT_FREE
高的 PCT_FREE 有助於避免索引塊的 ITL 爭用。當一個區塊內的所有可用 ITL 當前正在使用中，而且 Oracle 的 PCT_FREE 區域沒有足夠的空間來動態分配新的 ITL 插槽，那麼將發生 ITL 爭用。
參考
BUG:8735005 - SLOW INSERT - POSSIBLY DUE TO INDEX BLOCK SPLIT
BUG:19023318 - INDEX BLOCK SPLIT CAN CAUSE ENQ:TX-INDEX CONTENTION引用自："enq: TX - index contention" (文檔 ID 2331575.1)