概述

在Oracle数据库性能报告ASHRPT分析时，发现等待事件第一位的是enq: TX - row lock contention。这个等待事件消耗了绝大多数的CPU资源，导致系统整理性能下降。有些查询以前只要几个毫秒，现在变成了数分钟,下面看下ASH报告具体内容。

1、ASH报告

可以发现等待事件第一位的是enq: TX - row lock contention。

通常，产生enq: TX - row lock contention事件的原因有以下几种可能：

• 不同的session更新或删除同一条记录；
• 唯一索引有重复索引；
• 位图索引同时被更新或同时并发的向位图索引字段上插入相同字段值；
• 并发的对同一个数据块上的数据进行update操作；
• 等待索引块完成分裂；

2、ash报告sql信息

可以发现是这两条delete语句引起了enq: TX - row lock contention，均属于不同session，也就是前面所说的不同的session更新或删除同一条记录，也就是业务逻辑上的行锁冲突，如一条记录被多个人同时修改。这种锁对应的请求模式是6。如果是bitmap索引的更新冲突，就是多个会话同时更新bitmap索引的同一个数据块。此时会话请求锁的对应的请求模式是4。如果是唯一键冲突，如主键字段相同的多条记录同时插入。这种锁对应的请求模式是4。这也是应用逻辑问题。

DELETE FROM pub_alertsequence WHERE execution_time < '2019-08-12 02:00:02';
DELETE FROM pub_alertsequence WHERE execution_time < '2019-07-22 02:00:04'；

sql明细：

3、常用sql

3.1、查看系统中，当前有哪些会话产生了enq: TX - row lock contention等待事件？

select event,
 sid,
 p1,
 p2,
 p3,
 chr(bitand(p1, -16777216) / 16777215) ||
 chr(bitand(p1, 16711680) / 65535) "Name",
 (bitand(p1, 65535)) "Mode"
 from v$session_wait
 where event = 'enq: TX - row lock contention';
--150 692

3.2、查看系统中的当前会话，是在哪个对象上产生了产生了enq: TX - row lock contention等待事件？

select ROW_WAIT_OBJ#,ROW_WAIT_FILE#,ROW_WAIT_BLOCK#,ROW_WAIT_ROW# from v$session where event='enq: TX - row lock contention';
--89684

3.3、查看前面记录的数据库对象ROW_WAIT_OBJ#具体信息

select object_name,object_id from dba_objects where object_id=89684;

3.4、看看SID为150,692的会话到底在执行哪些操作导致enq: TX - row lock contention等待事件？

select sid, sql_text
 from v$session a, v$sql b
 where sid in(150, 692)
 and(b.sql_id = a.sql_id or b.sql_id = a.prev_sql_id);

3.5、查看锁信息

select * from v$lock where sid in (150,692);

以上就是针对enq: TX - row lock contention这类型等待事件的分析流程，后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~