**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，所以仍在回滚未提交的事务。

ITPub博客

常见队列等待事件处理思路

最新文章