oracle学习之行级锁的本质

时间：2017-07-11 来源：

　　㈠ 单实例Oracle locking机制

　　locking机制的三大组成部分：

　　① resource structure

　　Oracle对于每个需要“并发访问”的资源，都在SGA中用一个数据结构来描述它

　　这个结构叫resource structure

　　这个数据结构有三个成员：owner、waiter和converter

　　这是3个指针

　　指向由lock structure组成的链表的指针

　　其中，converter和waiter有些区别：

　　如果某个操作先后需要两种不同模式的锁，比如，先S，后X，则进程会先请求S，获得后lock structure会挂在owner上，

　　当需要X时，进行必须先释放S，然后再次申请X

　　但是可能无法立即获得

　　这时这个请求会被立即挂在converter下

　　converter的优先级高于waiter

　　根据v$lock的lmode和request可以判断他三：

　　● lmode > 0,request =0 → owner

　　● lmode = 0,request >0 → waiter

　　● lmode > 0,request >0 → converter

　　② lock structure

　　每当进程要访问共享资源时，必须先锁定该资源

　　锁定实际就是从SGA中申请一个lock structure

　　在其中记录lmode 、PID等

　　然后看能否立刻获得该资源的访问权

　　● 如果能，则把lock structure挂到resource structure的owner链表中

　　● 否则，把这个lock structure挂到resource structure的waiter链表中

　　③ enqueue算法

　　按先入先出原则分配锁

　　㈡ 行级锁

　　以上的locking机制需要resource、lock两种数据结构，适合粗粒度资源，但对于数据记录等细粒度的访问，无论从

　　内存需求还是维护成本，都是一个恶梦

　　Oracle的行级锁就是在这种场合下闪亮登场的

　　行级锁不是Oracle一般意义上的锁

　　虽然有锁的功能，但是没有锁的开销

　　行级锁根本没有相关开销，对1千万行锁定所需的资源数与对1行锁定所需的资源数完全相同，这是个常量：0和1

　　在Oracle的每行数据上，都有一个标志位来表示该行数据是否被锁定，要查看某一行是否被锁定，必须直接找到这一行，

　　而不要指望能从哪个列表得到答案

　　我们dump一个数据块，其transaction header的trc文件摘录如下：

　　Block header dump: 0x01000197

　　Object id on Block? Y

　　seg/obj: 0xcd8a csc: 0x00.a26fe itc: 2 flg: E typ: 1 - DATA

　　brn: 0 bdba: 0x1000191 ver: 0x01 opc: 0

　　inc: 0 exflg: 0

　　Itl Xid Uba Flag Lck Scn/Fsc

　　0x01 0x0001.005.00000100 0x0080000f.00ae.23 --U- 1 fsc 0x0000.000a2707

　　0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

　　其中 Lck字段就是行级锁的表示：1加锁，0不加锁

　　data header的部分trc摘录如下：

　　tab 0, row 0, @0x1f93

　　tl: 5 fb: --H-FL-- lb: 0x1 cc: 1

　　col 0: [ 1] 61

　　其中 lb => ITL number

　　其实，lb就是Itl

　　并发访问时，事务通过这个lb找到Itl，从而确定Lck的值，若为1，则挂到队列池

　　所以，当用户被阻塞时，不是被某条记录的行级锁阻塞，而是被TX锁阻塞

　　下面用实验证明之：

　　session_A

　　[email protected]> drop table t purge;

　　Table dropped.

　　[email protected]> create table demo (id number,name varchar2(10));

　　Table created.

　　[email protected]> insert into demo values(1,'bin');

　　1 row created.

　　[email protected]> insert into demo values(2,'think');

　　1 row created.

　　[email protected]> insert into demo values(3,'water');

　　1 row created.

　　[email protected]> commit;

　　Commit complete.

　　[email protected]> select * from demo;

　　ID NAME

　　---------- ----------

　　1 bin

　　2 think

　　3 water

　　[email protected]> savepoint a;

　　Savepoint created.

　　[email protected]> update demo set name='think big' where id=2;

　　1 row updated.

　　session_B

　　在session_B，并发修改同一条记录，会话被阻塞

　　[email protected]> update demo set name='think big' where id=2;

　　--被阻塞

　　此时在session_A回滚到之前的savepoint，这相当于撤销了对记录的修改

　　但是session_B仍然处于等待状态

　　这是因为session_B是被session_A的TX锁阻塞，而不是被session_A的行级锁阻塞

　　在session_C上进行查询：

　　[email protected]> select sid,lmode,request from v$lock where sid in (1081,1090);

　　SID LMODE REQUEST

　　---------- ---------- ----------

　　1090 0 6

　　1081 3 0

　　1090 3 0

　　1081 6 0

　　[email protected]> select sid,event from v$session where sid in (1081,1090);

　　SID EVENT

　　---------- ----------------------------------------------------------------

　　1081 SQL*Net message from client

　　1090 enq: TX - row lock contention

　　(以上内容摘于网络，如有侵权，请告之，将第一时间删除)