TX锁（Transaction Lock）分析

日期： 2007-05-07 14:50:13

分享到

前两天看到现场alert日志中有一些00060(Deadlock)的告警。查了一下日志文件，发现一些奇怪的现象，比如有些锁在Insert时产生的，有些死锁是对同一个对象产生的。于是在解决这些问题的同时，仔细研究了一下TX锁，总结了产生TX锁的各种情况。

数据记录被锁

我们知道，Oracle中事务产生的索都是行级锁。也就说，事务在对表做更新操作（Update、Delete）时，只在针对数据块中需要更新的数据记录加锁。这种类型的锁就是我们最常见的锁。看下面的例子：
SQL> create table t_lock(a number, b varchar2(20), c char(10)) initrans 1 maxtrans 3;
 
Table created
 
SQL> insert into t_lock values(1,1,1);
 
1 row inserted
 
SQL> commit;
 
Commit complete
 
会话1：
SQL> update t_lock set b='2' where a=1;
 
1 row updated
 
会话2：
SQL> delete t_lock where a=1;
 
会话1锁住了a=1的记录，会话试图删除该记录时，被hung住。
SQL> select * from dba_waiters;
 
WAITING_SESSION HOLDING_SESSION LOCK_TYPE MODE_HELD MODE_REQUESTED LOCK_ID1 LOCK_ID2
--------------- --------------- --------- --------- -------------- -------- --------
28            20              Transaction Exclusive Exclusive    1048671  40361
    
并且，如果将t_lock的数据块dump出来的话，也可以看到在记录行上的锁标志
tl: 19 fb: --H-FL-- lb: 0x1  cc: 3
其中，0x1对应的是产生锁的事务在数据块itl列表中的条目号。

数据块中itl条目达到最大限制时产生的锁
 
ITL(Interested Transaction List)直白点说就是对该数据块“有兴趣”的事务列。也就是会对该数据块进行修改的事务。一个表的数据块上同时最多可以有多少个事务对其进行更新，是由创建表时的参数maxtrans指定的。但是，如果表建立在基于9i新特性ASSM(自动段空间管理)的表空间上的话，那么指定的maxtrans就无效，一律都是255。比如上面的例子中，我们指定了maxtrans为3（表空间不是ASSM），所以同时最多只能有3个事务对一个数据块进行更新。看下面的例子。

先给上面的表多插入一些数据：
SQL> insert into t_lock values(2,2,2);
 
1 row inserted
 
SQL> insert into t_lock values(3,3,3);
 
1 row inserted
 
SQL> insert into t_lock values(4,4,4);
 
1 row inserted
 
SQL> insert into t_lock values(5,5,5);
 
1 row inserted
 
SQL> commit;
 
Commit complete
    
会话1：
SQL> update t_lock set b='2' where a=1;
 
1 row updated
    
会话2：
SQL> update t_lock set b='2' where a=2;
 
1 row updated
    
会话3：
SQL> update t_lock set b='2' where a=3;
 
1 row updated
    
会话4：
SQL> update t_lock set b='2' where a=4;
 
1 row updated
    
前面已经占用了3个itl slot，第4个事务再申请itl时被hung住了。
SQL> select * from dba_waiters;
 
WAITING_SESSION HOLDING_SESSION LOCK_TYPE MODE_HELD MODE_REQUESTED LOCK_ID1 LOCK_ID2
--------------- --------------- --------- --------- -------------- -------- --------
19            27              Transaction Exclusive Exclusive    1048671  40361
 
Dump出数据块，可以看到itl已经达到最大限制条目数：
seg/obj: 0x87c0  csc: 0x00.a337dee9  itc: 3  flg: -  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01
 
Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0008.053.00009ef3  0x00802e6a.71b4.2b  ----    1  fsc 0x0000.00000000
0x02   0x000d.037.0000a98a  0x0080655a.ac1f.2b  ----    1  fsc 0x0000.00000000
0x03   0x000c.004.0000acb9  0x008006a6.06bc.28  ----    1  fsc 0x0000.00000000
 
这里我们需要提出另外一个问题，如果事务操作不是update、delete，而是进行Insert操作，会不会也会达到maxtrans的限制呢？做个试验看下吧：

会话1：
SQL> update t_lock set b='2' where a=1;
 
1 row updated
    
会话2：
SQL> update t_lock set b='2' where a=2;
 
1 row updated
    
会话3：
SQL> update t_lock set b='2' where a=3;
 
1 row updated
 
会话4：
SQL> insert into t_lock values(6,6,6);
 
1 row inserted
    
这时，尽管已经分配itl条目给三个事务，但是第四个事务在做insert插入操作时并没有被hung住。

看下数据块dump内容：
Object id on Block? Y
 seg/obj: 0x87c0  csc: 0x00.a337df1b  itc: 3  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0xa03000c ver: 0x01
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0003.00b.0000a3ab  0x0080397c.0b0f.2a  ----    1  fsc 0x0000.00000000
0x02   0x0000.000.00000000  0x00806a5a.as1e.2b  ----    1  fsc 0x0000.00000000
0x03   0x000e.037.0000a458  0x14401ff2.17d8.2b  ----    1  fsc 0x0000.00000000
 
我们发现，确实只有三个transaction在这个数据块上。那么还有一个事务呢？别急，把下一个数据块dump出来看看：