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