[转]推荐:深入研究itl阻塞与itl死锁-凯发app官方网站

凯发app官方网站-凯发k8官网下载客户端中心 | | 凯发app官方网站-凯发k8官网下载客户端中心
  • 博客访问: 3976922
  • 博文数量: 536
  • 博客积分: 10470
  • 博客等级: 上将
  • 技术积分: 4825
  • 用 户 组: 普通用户
  • 注册时间: 2006-05-26 14:08
文章分类

全部博文(536)

文章存档

2024年(3)

2021年(1)

2019年(1)

2017年(1)

2016年(2)

2013年(2)

2012年(10)

2011年(43)

2010年(10)

2009年(17)

2008年(121)

2007年(252)

2006年(73)

相关博文
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·

分类: oracle

2007-10-31 21:23:55

首先要说的是,这个问题当初我是真遇到过,然后,就有了汪海的这篇文章:

itl deadlock:

但是ningoo 在下面回复说,10g模拟不到这样的情况了,开始我没有太在意,后来再想想,9i这么做的确是不对的,因为还有其它的进程可以释放资源,根本还没有达到死锁的条件。那么,10g就没有itl死锁了吗?也不是的,10g也有,不过是改进了一下,需要把所有的进程阻塞住的时候,才能爆发出死锁。

从死锁的原理上来看,10g是正确的,9i是欠完善的。我们现在完整的分析一下itl等待,以及itl死锁的前因后果,因为这部分在我的新书中也有涉及,属于比较难的一部分,先透露出来,免得大家到时候看书可能看得比较糊涂。

1、什么是itl

itl(interested transaction list)是oracle数据块内部的一个组成部分,用来记录该块所有发生的事务,一个itl可以看作是一个记录,在一个时间,可以记录一个事务(包括提交或者未提交事务)。当然,如果这个事务已经提交,那么这个itl的位置就可以被反复使用了,因为itl类似记录,所以,有的时候也叫itl槽位。

如果一个事务一直没有提交,那么,这个事务将一直占用一个itl槽位,itl里面记录了事务信息,回滚段的入口,事务类型等等。如果这个事务已经提交,那么,itl槽位中还保存的有这个事务提交时候的scn号。如dump一个块,就可以看到itl信息:
    itl           xid                  uba         flag  lck        scn/fsc
    0x01   0x0006.002.0000158e  0x0080104d.00a1.6e  --u-  734  fsc 0x0000.6c9deff0
    0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

对于已经提交的事务,itl槽位最好不要马上被覆盖,因为一致性读可能会用到这个信息,一致性读的时候,可能需要从这里获得回滚段的入口,并从回滚段中获得一致性读。

itl的个数,受参数initrans控制,最大的itl个数,受maxtrans控制,在一个块内部,默认分配了2个或3个itl的个数,如果这个块内还有空闲空间,那么oracle是可以利用这些空闲空间并再分配itl的。如果没有了空闲空间,那么,这个块因为不能分配新的itl,所以就可能发生itl等待。

如果在并发量特别大的系统中,最好分配足够的itl个数,其实它并浪费不了太多的空间,或者,设置足够的pctfree,保证itl能扩展,但是pctfree有可能是被行数据给消耗掉的,如update,所以,也有可能导致块内部的空间不够而导致itl等待。


2、itl等待

我们看一个itl等待的例子:
piner@10gr2>create table test(a int) pctfree 0 initrans 1;
table created.

我们这里指定pctfree为0,initrans为1,就是为了更观察到itl的真实等待情况,那么,现在,我们个这些块内插入数据,把块填满,让它不能有空间分配。
piner@10gr2>begin
  2       for i in 1..2000 loop
  3         insert into test values(i);
  4        end loop;
  5  end;
  6  /
pl/sql procedure successfully completed.
piner@10gr2>commit;
commit complete.

我们再检查数据填充的情况:
piner@10gr2>select f,b,count(*) from (
  2     select dbms_rowid.rowid_relative_fno(rowid) f,
  3            dbms_rowid.rowid_block_number(rowid) b
  4            from test) group by f,b;
 
         f          b   count(*)
---------- ---------- ----------
         1      29690        734
         1      29691        734
         1      29692        532

可以发现,这2000条数据分布在3个块内部,其中有2个块添满了,一个块是半满的。我们dump一个满的块,可以看到itl信息:
piner@10gr2>alter system dump datafile 1 block 29690;

回到os,在udump目录下,检查跟踪文件,可以看到如下的信息
    itl           xid                  uba         flag  lck        scn/fsc
    0x01   0x0006.002.0000158e  0x0080104d.00a1.6e  --u-  734  fsc 0x0000.6c9deff0
    0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

发现,采用如上参数创建的表,块内部默认有2个itl槽位,如果这里不指定initrans 1,默认是有3个itl槽位的。

因为只有2个itl槽位,我们可以用三个会话来模拟等待:

会话1,我们更新这个块内部的第一行:
piner@10gr2>update test set a=a
   2    where dbms_rowid.rowid_block_number(rowid)=29690
   3      and dbms_rowid.rowid_row_number(rowid)=1;
1 row updated.

会话2,我们更新这个块内部的第2行:
piner@10gr2>update test set a=a
   2    where dbms_rowid.rowid_block_number(rowid)=29690
   3      and dbms_rowid.rowid_row_number(rowid)=2;
1 row updated.

会话3(sid=153),我们更新这个块内部的第三行,发现被阻塞:
piner@10gr2>update test set a=a
   2    where dbms_rowid.rowid_block_number(rowid)=29690
   3      and dbms_rowid.rowid_row_number(rowid)=3;

可以看到,会话被阻塞

观察这个时候的等待事件,我们可以发现是itl等待:
piner@10gr2>select event from v$session_wait where sid=153
event
----------------------------
enq: tx - allocate itl entry

因为该块只有2个itl槽位,而现在发生了3个事务,而且,因为该块被数据添满,根本没有剩余的空间来分配新的itl,所以发生了等待。如果我们这个实验发生在半满的块29692上面,就发现进程3不会被阻塞,因为这里有足够的空间可以分配新的itl。


3、itl死锁

那么,理解了itl的阻塞,我们也就可以分析itl的死锁了,因为有阻塞,一般就能发生死锁。还是以上的表,因为有2个itl槽位,我们需要拿2个满的数据块,4个进程来模拟itl死锁:

会话1
piner@10gr2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29690
   3       and dbms_rowid.rowid_row_number(rowid)=1;
1 row updated.

会话2
piner@10gr2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29690
   3       and dbms_rowid.rowid_row_number(rowid)=2;
1 row updated.

会话3
piner@10gr2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29691
   3       and dbms_rowid.rowid_row_number(rowid)=1;
1 row updated.

会话4
piner@10gr2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29691
   3       and dbms_rowid.rowid_row_number(rowid)=2;
1 row updated.

以上4个进程把2个不同块的4个itl槽位给消耗光了,现在的情况,就是让他们互相锁住,达成死锁条件,回到会话1,更新块2,注意,以上4个操作,包括以下的操作,更新的根本不是同一行数据,主要是为了防止出现的是tx等待。
piner@10gr2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29691
   3       and dbms_rowid.rowid_row_number(rowid)=3;

发现被阻塞

那我们在会话3,更新块1,当然,也不是同一行
piner@10gr2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29690
   3       and dbms_rowid.rowid_row_number(rowid)=3;

被阻塞


注意,如果是9i,在这里就报死锁了,在进程1,我们可以看到
piner@9ir2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29691
   3       and dbms_rowid.rowid_row_number(rowid)=3;
update test set a=a
   where dbms_rowid.rowid_block_number(rowid)=29691 
     and dbms_rowid.rowid_row_number(rowid)=3
       *
error at line 1:
ora-00060: deadlock detected while waiting for resource

但是,在10g里面,这个时候,死锁是不会发生的,因为这里的进程1还可以等待进程4释放资源,进程3还可以等待进程2释放资源,只要进程2与进程4释放了资源,整个环境又活了,那么我们需要把这两个进程也塞住。

会话2,注意,我们也不是更新的同一行数据
piner@10gr2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29691
   3       and dbms_rowid.rowid_row_number(rowid)=4;

被阻塞

还有最后一个进程,进程4,我们也不更新同一行数据
piner@10gr2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29690
   3       and dbms_rowid.rowid_row_number(rowid)=4;

虽然,以上的每个更新语句,更新的都不是同一个数据行,但是,的确,所有的进程都被阻塞住了,那么,死锁的条件也达到了,马上,我们可以看到,进程1出现提示,死锁:
piner@10gr2>update test set a=a
   2     where dbms_rowid.rowid_block_number(rowid)=29691
   3       and dbms_rowid.rowid_row_number(rowid)=3;
 
update test set a=a
   where dbms_rowid.rowid_block_number(rowid)=29691
     and dbms_rowid.rowid_row_number(rowid)=3
       *
error at line 1:
ora-00060: deadlock detected while waiting for resource


4、itl等待与死锁的避免

为了避免以上的情况发生,我们一定要注意在高并发环境下的表中,正确的设置itl个数,如4个,8个等等,保证该块有足够的itl槽位,保证事务能顺利的进行,而没有itl的等待。关于itl的等待,在statspack的段报告中,也能很明显的看到:
    top 5 itl waits per segment for db: test  instance: test  snaps: 13013 -13014
    -> end segment itl waits threshold:       100

                                               subobject  obj.           itl
    owner      tablespace object name          name       type         waits  %total
    ---------- ---------- -------------------- ---------- ----- ------------ -------
    test       tbs_el_ind idx_llorder_orderid             index            3   75.00
    test       tbs_index2 idx_auc_feed_fdate              index            1   25.00

如果出现的频率很小,象上面的情况,一般可以不用干预,但是,如果waits很多,则表示这个对象有很严重的itl争用情况,需要增加itl个数。

另外注意的是,有itl等待,并不意味会发生itl死锁,从上面的例子可以看到,发生itl死锁的条件还是瞒苛刻的,如果发生了itl死锁,只能证明,你的系统中,itl等待已经非常严重了。

如果想增加initrans个数,参数可以动态修改,但是,只是针对以后的新块起效,以前的块如果想生效,需要在新参数下,重整表数据,如重建该表,或者move该表。

感觉原作者:piner 来源:
阅读(3389) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
")); function link(t){ var href= $(t).attr('href'); href ="?url=" encodeuricomponent(location.href); $(t).attr('href',href); //setcookie("returnouturl", location.href, 60, "/"); }
网站地图