**enq: TX - row lock contention**
		原因：事務未提交，導致其他會話無法獲取到該事物中涉及的行的TX鎖：global的，在對應節點找到堵塞者(block=1)程式
			分析：
查詢語句：

```
set line 200
SELECT inst_id,sid,type,id1,id2,lmode,request,block FROM gv$lock WHERE type='TX' order by id1,id2,block desc;
```

Block欄位為1的session為堵塞者，2表示堵塞是
				處理：
方法1：催促提交;
方法2：KILL -9 spid：
注意：KILL 前要檢查是否是LOCAL=NO的
			19C 如果使用了SRVICE，如果出現service飄移後，reload service回來.可能會出現較多enq: TX - row lock contention鎖。透過鎖語句和HANGANALZE，無法查到堵塞者。這個問題疑似是TAF的BUG，可以透過重建service（要求service裡不要帶taf引數設定），解決。命令如下：

```
srvctl add service -db newcbs -service newcbs1 -preferred newcbs1 -available newcbs2 -tafpolicy NONE
```

**enq: TX - index contention**
		    原因：
一般出現在對錶的高併發的DML操作時，當一個事務需要向一個索引塊插入資料時，該索引塊正好發生了索引分裂，則插入事務需要等待分裂事務
			分析
查詢分裂物件：
方法1：檢視該等待事件對應SQL的執行計劃，檢查這些SQL執行中正在使用的索引物件是哪些。
方法2：收集問題時段的AWR報告，檢查Segments by Row Lock Waits部分指標。
		   處理：
根據實際情況嚴重程度進行如下緊急處理：
a)降低應用併發度，降低index爭用；
b)使用反向索引重建（提升了寫效能，降低了讀效能），或使用hash分割槽重建索引；
如索引欄位使用sequence，可考慮增加sequence cache來增加鍵值跳度避免爭用
	**enq: TX - allocate ITL entry**
		原因：
‘enq: TX – allocate ITL entry’為分配ITL事務槽的等待，因為PCTFREE不足，BLOCK中沒有足夠空間分配ITL，ORACLE只能重用ITL，但是這個時候由於沒有 COMMIT，無法重用ITL，所以會出現allocate ITL等待事件。
		分析：
查詢ITL爭用物件：
方法1：檢視該等待事件對應SQL的執行計劃，檢查這些SQL執行中正在使用的物件是哪些。
方法2：收集問題時段的AWR報告，檢查Segments by ITL Waits部分指標部分指標。
		處理：
根據實際情況嚴重程度進行如下緊急處理：
a)降低應用併發度，避免ITL爭用；
停止應用，對爭用物件進行重建並增加inittrans大小 
	**enq: TM – contention**
		原因：1、對有事務執行的物件發起DDL操作。

2、手動對錶施加TM鎖。

3、INSERT /*+ APPEND */ INTO*

4、SQL*Loader 的direct path load

5、父子表外來鍵未建立索引
			分析：1、執行DML期間，為防止對與DML相關的物件進行結構修改，執行DML的程式必須對該表獲得3級的TM鎖。而此時如另一會話發起DDL語句，會請求6級的TM鎖，此時6級TM無法被獲取。（值得一提的是，不是所有的DDL都會引起TM鎖，經過測試alter table mary.tt add(remark varchar2(40))則會引起TX鎖，詳情可看Doc ID 1553725.1）

2、手動加鎖方式也會得到2級、6級TM鎖lock table tab_name in share mode;lock table tab_name in exclusive mode；

3、4、會獲得exclusive mode的TM鎖；

5、子表的外來鍵列沒有索引的狀態下，若父表的KEY被修改，則對子表以shared模式或shared -sub-exclusive模式獲得TM鎖。已獲得TM鎖一直擁有直到父表修改key的事務結束為止(commit或rollback)；
				處理：1、透過gv$session檢視中blocking_session判斷引起阻塞的會話，透過殺會話方式解決等待。

2、催促佔用資源的會話提交；

3、業務繁忙期間儘量減少DDL操作；
	**enq: HW - contention**
		原因：為防止多個程式同時修改HWM而提供的鎖稱為HW鎖。想要移動HWM的程式必須獲得HW鎖。若在獲取HW鎖過程中發生爭用，則等待enq: HW - contention事件。HW鎖爭用大部分是因大量執行insert所引發的，偶爾也會因大量執行update在回滾段中發生HW鎖爭用現象。若是update，表中段的擴充套件的大小雖然不多，但在建立回滾資料的過程中，需要回滾段的急速擴張。HW鎖爭用是在急速空間擴張時普遍出現的等待現象，有時也會引發嚴重的效能下降。
			處理：透過P3進行DBMS_UTILITY轉換可以獲知發生爭用的檔案和block：

```
 SQL>select dbms_utility.data_block_address_block(140003563) “block”,dbms_utility.data_block_address_file(140003563) “file” from dual; 
```

block    file ------   ------ 1591531   33進而透過file#和block#定位物件：

SQL> select owner, segment_type, segment_name from dba_extents where file_id = 33 and 1591531 between block_id and block_id + blocks - 1;

減少HW鎖爭用的方法如下：alter table  allocate extent，提前分配空間；

例：

```
alter table USER.TAB modify lob (COL_NAME) (allocate extent (size 64M));
```

分割槽表：

```
alter table USER.TAB modify partition par_Name lob (COL_NAME) (allocate extent (size 2g));
```

MOS相關文件：Doc ID 20687474.8 、 Doc ID 20687474.8
	**enq: SQ – contention 和 enq: SV - contention**
		![](http://img.blog.itpub.net/blog/2022/10/11/4bc80ed01a881987.png?x-oss-process=style/bb)
oracle為了管理SEQ使用了三種鎖
	**enq: US - contention**
		原因：enq: US – contention 說明事務在佇列中等待UNDO segment，通常由於UNDO空間不足導致。
			處理與分析：1、Undo資源不足，可能是undo_retention時間過長且設定為guarantee

```
SQL> select retention,tablespace_name from dba_tablespaces where tablespace_name like 'UNDO%';

RETENTION   TABLESPACE_NAME----------- ------------------------------NOGUARANTEE UNDOTBS1
```

2、檢視哪些事務消耗了UNDO

```
SQL> select owner,segment_name,bytes/1024/1024 from dba_segments where segment_type like '%UNDO%';

OWNER       SEGMENT_NAME         BYTES/1024/1024---------- ---------------     ---------------

SYS     _SYSSMU1_2223326396$     1.125SYS     _SYSSMU2_3361566992$     2.125SYS     _SYSSMU3_2168207262$     _
```

_1.125檢視回滾段的extents的狀態_

```
SQL> Select status, count(*) from dba_undo_extents where segment_name ='_SYSSMU10_3673383943$' group by status;

STATUS      COUNT(*)--------- ----------UNEXPIRED          1EXPIRED            
```

3如果全部為active，則說明有事務正在使用所有的擴充套件段，如果又找不到這樣的事務，可能原因是一個使用該回滾段的事務被異常終止了，被kill，所以仍在回滾未提交的事務。

常見佇列等待事件處理思路

相關文章