首页 > 代码库 > ORACLE等待事件：enq: TX - row lock contention

ORACLE等待事件：enq: TX - row lock contention

2024-08-14 00:13:25   222人阅读

enq: TX - row lock contention等待事件，这个是数据库里面一个比较常见的等待事件。enq是enqueue的缩写，它是一种保护共享资源的锁定机制，一个排队机制，先进先出(FIFO)。enq: TX - row lock contention等待事件，OACLE将其归类为application级别的等待事件。有些场景是因为应用逻辑设计不合理造成的。下面我们看看enq: TX - row lock contention的英文介绍：

This wait indicates time spent waiting for a TX lock, typically due to waiting to gain access to a row in a table that is currently locked by that transaction. The TX lock waited on is "TX-P2RAW-P3RAW" and the object / row that triggered the wait can usually be found in the ROW_WAIT_* columns of V$SESSION for the waiting session.

A TX lock is acquired when a transaction initiates its first change and is held until the transaction does a COMMIT or ROLLBACK. It is used mainly as a queuing mechanism so that other sessions can wait for the transaction to complete. The lock name (ID1 and ID2) of the TX lock reflect the transaction ID of the active transaction.

 

下面我们模拟一下enq: TX - row lock contention等待事件出现的场景，希望能对这个等待事件有较深的理解，主要参考了官方文档 ID 62354.1

1： Waits due to Row being locked by an active Transaction

这个是因为不同的session同时更新或删除同一个记录。例如，会话1持有row level lock，会话2在等待这个锁释放。准备测试环境和数据

SQL> create table test
  2  (  id number(10), 
  3     name varchar2(16)
  4  ) ;
 
Table created.
 
SQL> insert into test
  2  values(1001, ‘kk‘);
 
1 row created.
 
SQL> insert into test
 values(1002, ‘tttt‘)
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL>

 

 

会话1（会话ID为75）更新某一行

 

SQL> select sid from v$mystat where rownum =1;
 
       SID
----------
        75
 
SQL> update test set name=‘ken‘ where id=1001;
 
1 row updated.
 
SQL>

 

会话2（会话ID为200）也更新这一行（删除亦可）

 

 
SQL> select sid from v$mystat where rownum=1;
 
       SID
----------
       200
 
SQL> update test set name=‘kerry‘ where id=1001;  --一直被阻塞

 

在会话3中查看对应的会话、锁以及等待相关信息，这些SQL各

SQL> col type for a32;
SQL> SELECT sid,      
  2         type,     
  3         id1,      
  4         id2,      
  5         lmode,    
  6         request   
  7  FROM   v$lock    
  8  WHERE  type = ‘TX‘; 
 
       SID TYPE                                    ID1        ID2      LMODE    REQUEST
---------- -------------------------------- ---------- ---------- ---------- ----------
       200 TX                                   655385       2361          0          6
        75 TX                                   655385       2361          6          0
 
SQL> COL event FOR a36; 
SQL> SELECT sid, 
  2         Chr(Bitand(p1, -16777216) / 16777215) 
  3         || Chr(Bitand(p1, 16711680) / 65535) "name", 
  4         ( Bitand(p1, 65535) )                "mode", 
  5         event, 
  6         sql_id, 
  7         final_blocking_session 
  8  FROM   v$session 
  9  WHERE  event LIKE ‘enq%‘; 
 
       SID name           mode EVENT                                SQL_ID        FINAL_BLOCKING_SESSION
---------- -------- ---------- ------------------------------------ ------------- ----------------------
       200 TX                6 enq: TX - row lock contention        cz4tvs78skhus                     75
 
SQL> COL wait_class FOR A32;  
SQL> SELECT inst_id, 
  2         blocking_session, 
  3         sid, 
  4         serial#, 
  5         wait_class, 
  6         seconds_in_wait 
  7  FROM   gv$session 
  8  WHERE  blocking_session IS NOT NULL 
  9  ORDER  BY blocking_session;
 
   INST_ID BLOCKING_SESSION        SID    SERIAL# WAIT_CLASS                       SECONDS_IN_WAIT
---------- ---------------- ---------- ---------- -------------------------------- ---------------
         1               75        200      12230 Application                                  179
 
SQL> COL TX FOR A24;
SQL> SELECT 
  2     sid, seq#, state, seconds_in_wait,
  3     ‘TX-‘||lpad(ltrim(p2raw,‘0‘),8,‘0‘)||‘-‘||lpad(ltrim(p3raw,‘0‘),8,‘0‘) TX,
  4     trunc(p2/65536)      XIDUSN,
  5     trunc(mod(p2,65536)) XIDSLOT,
  6     p3                   XIDSQN
  7    FROM v$session_wait 
  8   WHERE event=‘enq: TX - row lock contention‘;
 
       SID       SEQ# STATE               SECONDS_IN_WAIT TX                           XIDUSN    XIDSLOT     XIDSQN
---------- ---------- ------------------- --------------- ------------------------ ---------- ---------- ----------
       200         46 WAITING                         203 TX-000A0019-00000939             10         25       2361
 
SQL> col event for a36 
SQL> col username for a10 
SQL> col sql_fulltext for a80 
SQL> SELECT g.inst_id, 
  2         g.sid, 
  3         g.serial#, 
  4         g.event, 
  5         g.username, 
  6         g.sql_hash_value, 
  7         s.sql_fulltext 
  8  FROM   gv$session g, 
  9         v$sql s 
 10  WHERE  g.wait_class = ‘Application‘ 
 11         AND g.sql_hash_value = http://www.mamicode.com/s.hash_value;
 
   INST_ID        SID    SERIAL# EVENT                          USERNAME   SQL_HASH_VALUE SQL_FULLTEXT
---------- ---------- ---------- ----------------------------- -----------  ------------- ---------------------------------
         1        200      12230 enq: TX - row lock contention    TEST       3515433816   update test set name=‘kerry‘ where id=1001
 
SQL> col type for a12;
SQL> select /*+rule*/
  2         inst_id,
  3         decode(request, 0, ‘holder‘, ‘waiter‘) role,
  4         sid,
  5         type,
  6         request,
  7         lmode,
  8         block,
  9         ctime,
 10         id1,
 11         id2
 12  from gv$lock            
 13  where (id1, id2, type) in            
 14                  (select id1, id2, type from gv$lock where request >0)
 15  order by ctime desc ,role; 
 
   INST_ID ROLE          SID TYPE            REQUEST      LMODE      BLOCK      CTIME        ID1        ID2
---------- ------ ---------- ------------ ---------- ---------- ---------- ---------- ---------- ----------
         1 holder         75 TX                    0          6          1        255     655385       2361
         1 waiter        200 TX                    6          0          0        245     655385       2361

技术分享

 

此时只能等待持有锁的会话commit或者rollback。 通常为会话1在某行上执行 update/delete 未提交，会话2对同一行数据进行 update/delete，或其它原因（例如SQL性能差）造成的锁释放速度缓慢或网络问题，都会造成后续的会话进入队列等待。

 

2：Waits due to Unique or Primary Key Constraint Enforcement

表上存在主键或唯一索引，会话1插入一个值（未提交），会话2同时或随后也插入同样的值;会话提交后1，enq: TX - row lock contention消失。

SQL> drop table test purge;
 
Table dropped.
 
SQL> create table test                                    
  2  (
  3     id  number(10), 
  4     name varchar(16), 
  5     constraint pk_test primary key(id)
  6  );
 
Table created.

 

 

会话1（会话ID为8）

SQL> insert into test values(1000, ‘kerry‘);
 
1 row created.

 

会话2（会话ID为14）

SQL> insert into test values(1000,‘jimmy‘);

会话3 在会话3中查看对应的会话、锁、以及等待信息

SQL> col type for a32;
SQL> SELECT sid,      
  2         type,     
  3         id1,      
  4         id2,      
  5         lmode,    
  6         request   
  7  FROM   v$lock    
  8  WHERE  type = ‘TX‘;   
 
       SID TYPE                                    ID1        ID2      LMODE    REQUEST
---------- -------------------------------- ---------- ---------- ---------- ----------
        14 TX                                   589835       2213          0          4
        14 TX                                   393232       2160          6          0
         8 TX                                   589835       2213          6          0
 
SQL> col event for a40 
SQL> col username for a10 
SQL> col sql_fulltext for a80 
SQL> SELECT g.inst_id, 
  2         g.sid, 
  3         g.serial#, 
  4         g.event, 
  5         g.username, 
  6         g.sql_hash_value, 
  7         s.sql_fulltext 
  8  FROM   gv$session g, 
  9         v$sql s 
 10  WHERE  g.wait_class = ‘Application‘ 
 11         AND g.sql_hash_value = http://www.mamicode.com/s.hash_value;  
 
   INST_ID        SID    SERIAL# EVENT                         USERNAME   SQL_HASH_VALUE SQL_FULLTEXT
---------- ---------- ---------- ----------------------------- ---------- --------------  ----------------------
         1         14      13392 enq: TX - row lock contention  TEST        874051616    insert into test values(1000,‘jimmy‘)
 
SQL> col type for a12;
SQL> select /*+rule*/
  2         inst_id,
  3         decode(request, 0, ‘holder‘, ‘waiter‘) role,
  4         sid,
  5         type,
  6         request,
  7         lmode,
  8         block,
  9         ctime,
 10         id1,
 11         id2
 12  from gv$lock
 13  where (id1, id2, type) in
 14                  (select id1, id2, type from gv$lock where request >0)
 15  order by ctime desc ,role; 
 
   INST_ID ROLE                SID TYPE            REQUEST      LMODE      BLOCK      CTIME        ID1        ID2
---------- ------------ ---------- ------------ ---------- ---------- ---------- ---------- ---------- ----------
         1 holder                8 TX                    0          6          1         92     589835       2213
         1 waiter               14 TX                    4          0          0         70     589835       2213

 

会话1（会话ID为8）提交事务后

 

SQL> insert into test values(1000, ‘kerry‘);
 
1 row created.
 
SQL> commit;

 

会话2（会话ID为14）遇到ORA-00001错误提示

SQL> insert into test values(1000,‘jimmy‘);
insert into test values(1000,‘jimmy‘)
*
ERROR at line 1:
ORA-00001: unique constraint (TEST.PK_TEST) violated

这个在ORACLE 10g以及以上版本都无法测试（Oracle 9i可以测试），因为ORACLE 10g中，对于单个数据块，Oracle缺省最大支持255个并发，MAXTRANS参数在ORACLE 10g以及以上版本被废弃了，即使你使用下面SQL指定了maxtrans为1， 但是你查看表的定义，你会发现maxtrans依然为255。

SQL> drop table test purge;
 
Table dropped.
 
 
SQL> create table test 
  2  (
  3     id  number(10), 
  4     name varchar(16)
  5  )  initrans 1 maxtrans 1;
 
Table created.

所以这个场景只会发生在ORACLE 9i的版本中或是并发非常高的系统当中。

 

Waits due to rows being covered by the same BITMAP index fragment

这个源于位图索引的特性，更新位图索引的一个键值，会指向多行记录，所以更新一行就会把该键值指向的所有行锁定

SQL> create table employee 
  2  (
  3  employee_id  number(10),
  4  employee_name nvarchar2(24),
  5  sex    varchar2(6) 
  6  );
 
Table created.
 
SQL> create bitmap index idx_employee_bitmap on employee(sex);
 
Index created.
 
SQL> insert into employee
  2  select 1000, ‘kerry‘, ‘female‘ from dual union all
  3  select 1001, ‘jimmy‘, ‘female‘ from dual;
 
2 rows created.
 
SQL> commit;
 
Commit complete.
 
SQL> 
 
 
会话1：
 
SQL> update employee set sex=‘male‘ where employee_id=1000;
 
1 row updated.
 
 
会话2：
 
SQL> update employee set sex=‘male‘ where employee_id=1001;
 
 
 
会话3：
SQL> col type for a32;
SQL> SELECT sid,      
  2         type,     
  3         id1,      
  4         id2,      
  5         lmode,    
  6         request   
  7  FROM   v$lock    
  8  WHERE  type = ‘TX‘;  
 
       SID TYPE                                    ID1        ID2      LMODE    REQUEST
---------- -------------------------------- ---------- ---------- ---------- ----------
        14 TX                                   589836       2211          0          4
        14 TX                                   131096       2204          6          0
         8 TX                                   589836       2211          6          0
 
SQL> col event for a40 
SQL> col username for a10 
SQL> col sql_fulltext for a80 
SQL> SELECT g.inst_id, 
  2         g.sid, 
  3         g.serial#, 
  4         g.event, 
  5         g.username, 
  6         g.sql_hash_value, 
  7         s.sql_fulltext 
  8  FROM   gv$session g, 
  9         v$sql s 
 10  WHERE  g.wait_class = ‘Application‘ 
 11         AND g.sql_hash_value = http://www.mamicode.com/s.hash_value;  
 
   INST_ID        SID    SERIAL# EVENT                          USERNAME   SQL_HASH_VALUE SQL_FULLTEXT
---------- ---------- ---------- ------------------------------ ---------- -------------- ---------------------------------
         1         14      13392 enq: TX - row lock contention   EST           2418349426 update employee set sex=‘male‘ where employee_id=1001
 
SQL> col type for a12;
SQL> select /*+rule*/
  2         inst_id,
  3         decode(request, 0, ‘holder‘, ‘waiter‘) role,
  4         sid,
  5         type,
  6         request,
  7         lmode,
  8         block,
  9         ctime,
 10         id1,
 11         id2
 12  from gv$lock
 13  where (id1, id2, type) in
 14                  (select id1, id2, type from gv$lock where request >0)
 15  order by ctime desc ,role;    
 
   INST_ID ROLE                SID TYPE            REQUEST      LMODE      BLOCK      CTIME        ID1        ID2
---------- ------------ ---------- ------------ ---------- ---------- ---------- ---------- ---------- ----------
         1 holder                8 TX                    0          6          1        116     589836       2211
         1 waiter               14 TX                    4          0          0         76     589836       2211
 
SQL>

 

其它场景

There are other wait scenarios which can result in a SHARE mode wait for a TX lock but these are rare compared to the examples given above.

Example:

If a session wants to read a row locked by a transaction in a PREPARED state then it will wait on the relevant TX lock in SHARE mode (REQUEST=4). As a PREPARED transaction should COMMIT , ROLLBACK or go to an in-doubt state very soon after the prepare this is not generally noticeable.

例如，表存在主外键读情况,主表不提交,子表那么必须进行等待.

初始化测试表

SQL> create table employee( employee_id  number, employee_name varchar(12), depart_id number);
 
Table created.
 
SQL> create table department(depart_id  number primary key, depart_name varchar2(24));
 
Table created.

 

会话1：

 
SQL> select sid from v$mystat where rownum=1;
 
       SID
----------
        75
 
SQL> insert into department values(1000, ‘sales‘);
 
1 row created.

 

会话2：

SQL> select sid from v$mystat where rownum=1;
 
       SID
----------
       200
 
SQL> insert into employee values(1024, ‘kerry‘, 1000); --一直挂起，直到会话1提交

 

 

会话3

SQL> show user;
USER is "SYS"
SQL> select sid from v$mystat where rownum=1;
 
       SID
----------
        73
 
SQL> col type for a12;
SQL> select /*+rule*/
  2         inst_id,
  3         decode(request, 0, ‘holder‘, ‘waiter‘) role,
  4         sid,
  5         type,
  6         request,
  7         lmode,
  8         block,
  9         ctime,
 10         id1,
 11         id2
 12  from gv$lock            
 13  where (id1, id2, type) in            
 14                  (select id1, id2, type from gv$lock where request >0)
 15  order by ctime desc ,role;  
 
   INST_ID ROLE          SID TYPE            REQUEST      LMODE      BLOCK      CTIME        ID1        ID2
---------- ------ ---------- ------------ ---------- ---------- ---------- ---------- ---------- ----------
         1 holder         75 TX                    0          6          1        197     458758       2371
         1 waiter        200 TX                    4          0          0         97     458758       2371
 
 
SQL> COL TX FOR A24;
SQL> SELECT 
  2     sid, seq#, state, seconds_in_wait,
  3     ‘TX-‘||lpad(ltrim(p2raw,‘0‘),8,‘0‘)||‘-‘||lpad(ltrim(p3raw,‘0‘),8,‘0‘) TX,
  4     trunc(p2/65536)      XIDUSN,
  5     trunc(mod(p2,65536)) XIDSLOT,
  6     p3                   XIDSQN
  7    FROM v$session_wait 
  8   WHERE event=‘enq: TX - row lock contention‘;
 
       SID       SEQ# STATE               SECONDS_IN_WAIT TX                           XIDUSN    XIDSLOT     XIDSQN
---------- ---------- ------------------- --------------- ------------------------ ---------- ---------- ----------
       200        108 WAITING                         145 TX-00070006-00000943              7          6       2371
 
SQL>

 

 

另外遇到enq: TX - row lock contention等待事件，单实例与RAC是否有所区别呢，如果是RAC，需要注意识别实例，否则很容易误杀其它会话？如果你查到了blocker，是不是应该直接kill掉呢？ 这个必须要先征询客户的意见，确认之后才可以杀掉。不能因为外在压力和自己的急躁而擅自Kill会话。

在WAITEVENT: "enq: TX - row lock contention" Reference Note (文档 ID 1966048.1)中，也有一些比较有意思的SQL，可以参考一下

SQL> SELECT row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#
  2    FROM v$session
  3   WHERE event=‘enq: TX - row lock contention‘
  4     AND state=‘WAITING‘;
 
ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#
------------- -------------- --------------- -------------
        75389              4             211             0
 
 
SQL> set linesize 240;
SQL> select owner, object_name from dba_objects
  2  where object_id=75389;  
 
OWNER                          OBJECT_NAME
------------------------------ ------------------
TEST                           TEST
 
 
SQL> SELECT 
  2     sid, seq#, state, seconds_in_wait,
  3     ‘TX-‘||lpad(ltrim(p2raw,‘0‘),8,‘0‘)||‘-‘||lpad(ltrim(p3raw,‘0‘),8,‘0‘) TX,
  4     trunc(p2/65536)      XIDUSN,
  5     trunc(mod(p2,65536)) XIDSLOT,
  6     p3                   XIDSQN
  7    FROM v$session_wait 
  8   WHERE event=‘enq: TX - row lock contention‘
  9  ;
 
       SID       SEQ#            SECONDS_IN_WAIT        TX                    XIDUSN    XIDSLOT     XIDSQN
---------- ---------- --------- --------------- --------------------------- ---------- ---------- ----------
       137         27 WAITING                     245 TX-00040012-000007E6        4         18       2022

在TX - row lock contention 的一些场景 这篇文章里面介绍了出现enq: TX - row lock contention等待的案例场景，网络问题、执行计划问题、应用问题等。在我遇到的实际案例当中，网络问题造成的‘enq: TX - row lock contention‘较多，因为现在大多数是无线网络，有些应用程序出现问题或网络出现问题过后，导致数据库中的进程依然在，但是对于的UPDATE等DML操作没有及时提交。从而出现较严重的enq: TX - row lock contention

 

诊断定位enq: TX - row lock contention等待事件

在官方文档 ID 62354.1里面，提供了一个根据AWR 快照ID查找那些段出现row lock 等待较多的SQL，这个也有一定的参考意义。

SELECT P.snap_id,
  P.begin_interval_time,
  O.owner,
  O.object_name,
  O.subobject_name,
  O.object_type,
  S.row_lock_waits_delta
FROM dba_hist_seg_stat S,
  dba_hist_seg_stat_obj O,
  dba_hist_snapshot P
WHERE S.dbid               =O.dbid
AND S.ts#                  =O.ts#
AND S.obj#                 =O.obj#
AND S.dataobj#             =O.dataobj#
AND S.snap_id              =P.snap_id
AND S.dbid                 =P.dbid
AND S.instance_number      =P.instance_number
AND S.row_lock_waits_delta > 0
AND P.snap_id BETWEEN      <begin_snap>  AND <end_snap> 
ORDER BY 1,3,4;

一般最常用的还是AWR报告结合ASH报告来诊断、定位enq: TX - row lock contention等待事件，另外，在TX - row lock contention 的一些场景这篇分享文章中，对如何减少enq: TX - row lock contention等待做了一些总结，具体如下：

 

在一些事务频繁，并发较高的环境下，为了尽可能减少 TX - row lock contention 等待事件的发生，应当从应用设计到数据库多个层面进行考虑。

应用层面：

1、约束通常是为了保证数据完整性，在并发场景下，应充分考虑事务进行的逻辑顺序，避免多个会话事务交叉进行，触发约束冲突在事务级别发生竞争；

2、要提高并发效率，应当尽可能拆分大事务为小事务，提高 tx enqueue 锁的获取释放速度；

3、如果要使用悲观锁（for update），应尽可能减少锁定的行范围；

数据库层面：

1、在 dml 频繁的表上建立适当的索引，提高 SQL 执行的效率，减少 tx enqueue 锁持有的时间；避免全表扫描这种，容易造成 IO 开销巨大，热块竞争，会话堆积的访问方式。

2、在 dml 频繁的表上不应使用位图索引；

3、对于 dml 频繁的表，不应使用 IOT 表，物化视图等；

4、RAC 环境下，对于批量的 dml 操作，尽可能固定在单一节点，尽量降低网络开销、集群竞争、一致性块获取和日志刷盘等带来的影响。

 

参考资料：

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=521417992978367&id=62354.1&displayIndex=1&_afrWindowMode=0&_adf.ctrl-state=1d01vq0378_227

http://mp.weixin.qq.com/s?__biz=MjM5MzExMTU2OQ==&mid=2650603515&idx=1&sn=275956ad38d26168e44027336644e5a0&scene=2&srcid=0711qxhIykeqO278x7VZFx5k&from=timeline&isappinstalled=0#wechat_redirect

http://www.dbform.com/html/2015/2317.html

http://www.killdb.com/2015/07/13/%E5%85%B3%E4%BA%8Eenq-tx-row-lock-contention%E7%9A%84%E6%B5%8B%E8%AF%95%E5%92%8C%E6%A1%88%E4%BE%8B%E5%88%86%E6%9E%90.html

http://blog.chinaunix.net/uid-23284114-id-3390180.html

http://yunlongzheng.blog.51cto.com/788996/411205

ORACLE等待事件：enq: TX - row lock contention


联系
我们