Oracle 行级锁的开销

首先来复习一下行级锁的机制。当一个事务开始时必选先申请一个TX锁（保护回滚段、回滚数据块），只有先申请到回滚段资源后才能开始一个事务，才能进行DML操作。这个动作完成后，事务就可以开始修改数据了。当修改数据表的记录时，遵循以下的操作顺序。

1.获得表的TM锁（保护事务执行过程中其它用户不能修改表结构）

2.在要修改的数据块头部的ITL表中申请一个空闲表项，记录事务号，实际记录的是这个事务要使用的回滚段地址。

3.修改数据块的某条记录时，设置该记录头部的ITL索引指向第2步申请的表项，然后再修改记录内容。修改前需要在回滚段对记录修改前的记录状态做一个copy。

4.当其它用户想并发修改这条记录时，会根据记录头的ITL索引读取数据块头部ITL表项的内容，查看这个事务是否已经提交。

5.如果没有提交，这个用户会等待前一个用户的TX锁的释放。

从上面的工作机制可以看出，无论一个事务修改多少个表的多少记录，该事务真正需要的只是一个TX锁和每个表的TM锁，内存开销非常小。所谓的行级锁只是数据块头、数据记录头的一些字段。所以ORACLE的行级锁虽然有锁的功能，但是没有锁的开销。

举例证明一下：

会话1：

SQL> select * from test;

        ID
----------
        12
        16
        18

SQL> savepoint s;

保存点已创建。

SQL> update test set id=19 where id=18;

已更新 1 行。

会话2：

SQL> conn sjh/sjh
已连接。
SQL> update test set id=190 where id=18;

--在等待...

会话1：

SQL> rollback to s;

回退已完成。

--会话2继续等待...

会话3：

SQL> select username,event,sid,blocking_session from v$session where username='S
JH';

USERNAME
------------------------------
EVENT                                                                   SID
---------------------------------------------------------------- ----------
BLOCKING_SESSION
----------------
SJH
enq: TX - row lock contention                                           140
             141

SJH
SQL*Net message from client                                             141

--发现TX竞争。会话2在等待会话1释放TX锁。

会话1：

SQL> rollback;

回退已完成。

会话2：

SQL> update test set id=190 where id=18;
update test set id=190 where id=18
                   *
第 1 行出现错误:
ORA-01438: 值大于为此列指定的允许精度

SQL> desc test;
名称                                      是否为空? 类型
----------------------------------------- -------- ------------

ID                                                 NUMBER(2)

会话3：

SQL> select username,event,sid,blocking_session from v$session where username='S
JH';

USERNAME
------------------------------
EVENT                                                                   SID
---------------------------------------------------------------- ----------
BLOCKING_SESSION
----------------
SJH
SQL*Net message from client                                             140

SJH
SQL*Net message from client                                             141

--等待消失