首先来复习一下行级锁的机制。当一个事务开始时必选先申请一个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
--等待消失。
阅读(6264) | 评论(0) | 转发(0) |