等待事件enq: TX - row lock contention等待时间长

刘泽宇

在查看数据库的AWR报告时，发现在等待事件中存在一个事件enq: TX - row lock contention，等待时间很长
在网上查找到了会造成这个事件等待时间长的原因：
enq: TX - row lock contention 通常是Application级别的问题。
通常情况下，Oracle数据库的等待事件enq: TX - row lock contention会在下列三种情况下会出现。

（一）第一种情况，是真正的业务逻辑上的行锁冲突，如一条记录被多个人同时修改。

这种锁对应的请求模式是6（Waits for TX in mode 6 ：A 会话持有row level lock，B会话等待这个lock释放。）。

不同的session更新或删除同一个记录。（This occurs when one application is updating or deleting a row that another session is also trying to update or delete. ）

解决办法：持有锁的会话commit或者rollback。

（二）第二种情况，是唯一键冲突（In mode 4,唯一索引），如主键字段相同的多条记录同时插入。

这种锁对应的请求模式是4。这也是应用逻辑问题。

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

解决办法：持有锁的会话commit或者rollback。

（三）第三种情况，是bitmap索引的更新冲突（in mode 4 :bitmap），就是多个会话同时更新bitmap索引的同一个数据块。

源于bitmap的特性：位图索引的一个键值，会指向多行记录，所以更新一行就会把该键值指向的所有行锁定。此时会话请求锁的对应的请求模式是4。

bitmap索引的物理结构和普通索引一样，也是 B-tree 结构,但它存储的数据记录的逻辑结构为"key_value,start_rowid,end_rowid,bitmap"。

其内容类似这样："‘8088’,00000000000,10000034441,1001000100001111000"

Bitmap是一个二进制，表示 START_ROWID 到 END_ROWID 的记录，1 表示等于 key_value即‘8088’的 ROWID 记录， 0 则表示不是这个记录。

解决办法：持有锁的会话commit或者rollback。

综上，解决这个事件等待时间长的方法就是将持有锁的会话及时进行commit或者rollback。