Oracle行级锁的本质

㈠ 单实例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

sys@ORCL> drop table t purge;

Table dropped.

sys@ORCL> create table demo (id number,name varchar2(10));

Table created.

sys@ORCL> insert into demo values(1,'bin');

1 row created.

sys@ORCL> insert into demo values(2,'think');

1 row created.

sys@ORCL> insert into demo values(3,'water');

1 row created.

sys@ORCL> commit;

Commit complete.

sys@ORCL> select * from demo;

        ID NAME
---------- ----------
         1 bin
         2 think
         3 water

sys@ORCL> savepoint a;

Savepoint created.

sys@ORCL> update demo set name='think big' where id=2;

1 row updated.
  

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

sys@ORCL> update demo set name='think big' where id=2;
      --被阻塞

此时在session_A回滚到之前的savepoint，这相当于撤销了对记录的修改
但是session_B仍然处于等待状态
这是因为session_B是被session_A的TX锁阻塞，而不是被session_A的行级锁阻塞
在session_C上进行查询：

sys@ORCL> 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

sys@ORCL> 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