在Oracle数据库性能报告AWRRPT分析时，发现top 5等待事件第一位的是enq: TX - row lock contention。这个等待事件消耗了绝大多数的CPU资源，导致系统整理性能下降。有些查询以前只要几个毫秒，现在变成了数分钟。CPU使用率长时间维持在100%。

?声明一下，数据库版本是10g for linux x86 64bit。

在AWRRPT中看到的top 5等待如下：

Top 5 Timed Events
Event    Waits    Time(s)    Avg Wait(ms)    % Total Call Time    Wait Class
enq: TX - row lock contention    27,190    62,674    2,305    63.1    Application
CPU time         36,227         36.5     
log file sync    133,744    52    0    .1    Commit
log file parallel write    143,992    29    0    .0    System I/O
db file sequential read    49,403    23    0    .0    User I/O

?

(miki西游 @mikixiyou 原文链接: http://mikixiyou.iteye.com/blog/1771648)

?

通常情况下，Oracle数据库的等待事件enq: TX - row lock contention会在下列三种情况下会出现。

第一种情况，是真正的业务逻辑上的行锁冲突，如一条记录被多个人同时修改。这种锁对应的请求模式是6。

第二种情况，是唯一键冲突，如主键字段相同的多条记录同时插入。这种锁对应的请求模式是4。这也是应用逻辑问题。

第三种情况，是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 则表示不是这个记录。

在了解bitmap索引的结构之后，我们就能理解同时插入多条记录到拥有bitmap索引的表时，就会同时更新bitmap索引中一个块中的记录，等于某一个记录被同时更新，自然就会出现行锁等待。插入并发量越大，等待越严重。

等待事件enq: TX - row lock contention中的enq是enquence的简写。enquence是协调访问数据库资源的内部锁。

所有以“enq:”打头的等待事件都表示这个会话正在等待另一个会话持有的内部锁释放，它的名称格式是enq:enqueue_type - related_details。这里的enqueue_type是TX，related_details是row lock contention。数据库动态性能视图v$event_name提供所有以“enq:”开头的等