评论: 推荐：深入研究ITL阻塞与ITL死锁

作者: big_bear

big_bear — Tue, 15 May 2007 02:17:30 +0000

支持，写的简明扼要。
能够把死锁产生的trace文件再稍加分析，itl死锁和普通的死锁产生的trace有什么不一样，不过我系统ALERT.LOG文件中发现了死锁日志，怎么去分析TRACE中的文件从而准确判断死锁发生的原因呢？
谢谢！

作者: piner

piner — Tue, 15 May 2007 02:29:58 +0000

trace文件都是一样的，从trace不好分别这些类型，只能发现死锁的graph，如果非要找差别，估计只能看下面的Rows waited on，不是数据行(no raw)的等待：

    Deadlock graph:
                           ---------Blocker(s)--------  ---------Waiter(s)---------
    Resource Name          process session holds waits  process session holds waits
    TX-0006001e-0000158d        12     146     X             18     153           S
    TX-00090012-0000157f        18     153     X             17     145           S
    TX-000a0010-00002a98        17     145     X             16     149           S
    TX-0008001d-0000158d        16     149     X             12     146           S
    session 146: DID 0001-000C-00000033     session 153: DID 0001-0012-00000012
    session 153: DID 0001-0012-00000012     session 145: DID 0001-0011-00000074
    session 145: DID 0001-0011-00000074     session 149: DID 0001-0010-000000A3
    session 149: DID 0001-0010-000000A3     session 146: DID 0001-000C-00000033
    Rows waited on:
    Session 153: no row
    Session 145: no row
    Session 149: no row
    Session 146: no row

作者: 马艺桐

马艺桐 — Tue, 15 May 2007 02:36:54 +0000

普通死锁是指的是对相同行的update或者delete的死锁，ITL指的是SEGMENT ITL资源争用引起的死锁。从trace文件中应该可以看到详细信息的：是ITL死锁还是普通的死锁。

作者: 马艺桐

马艺桐 — Tue, 15 May 2007 02:44:18 +0000

也可以使用如下查询，查到数据库当前的ITL等待：
select owner, object_name, subobject_name, object_type, tablespace_name, value, statistic_namefrom v$segment_statistics where statistic_name = ’ITL waits’and value > 0order by value;

作者: piner

piner — Tue, 15 May 2007 02:45:27 +0000

再看了一下，下面的信息也还有点用：

ITL死锁

last wait for 'enq: TX - allocate ITL entry' blocking sess=0x0x3f2ff954 seq=79 wait_time=2929827 seconds since wait started=213
name|mode=54580004, usn<<16 | slot=8001d, sequence=158d
Dumping Session Wait History

普通死锁与位图索引死锁

last wait for 'enq: TX - row lock contention' blocking sess=0x0x3f2ff954 seq=592 wait_time=2929819 seconds since wait started=18
name|mode=54580004, usn<<16 | slot=7000a, sequence=1570
Dumping Session Wait History

作者: piner

piner — Tue, 15 May 2007 02:46:54 +0000

[quote]也可以使用如下查询，查到数据库当前的ITL等待：select owner, object_name, subobject_name, object_type, tablespace_name, value, statistic_namefrom v$segment_statistics where statistic_name = ’ITL waits’and value > 0order by value;[/quote]

这个查询的时间跨度太大了，是系统开启以来的。

作者: anysql

anysql — Wed, 16 May 2007 01:12:49 +0000

一个ITL只占24个字节, 是可以默认就多给几个的.

作者: NinGoo

NinGoo — Wed, 16 May 2007 05:36:27 +0000

呵呵，这个解释得比较清楚了，9i的ITL死锁检测确实是不合理的，所以10g做了修正

作者: wxy0327

wxy0327 — Tue, 22 May 2007 06:51:39 +0000

顶

作者: big_bear

big_bear — Fri, 29 Jun 2007 10:05:08 +0000

多谢版主的文章，刚在这里学习完就碰到了这样的情况。附上发生死锁的部分TRACE文件中的信息，从这个文件中也可以看到ITL竞争是很激烈，然后并发大的时候最后导致死锁的。
last wait for ‘enq: TX - allocate ITL entry’ blocking sess=0×0x10da2a450 seq=34603 wait_time=2930318 secon
ds since wait started=9
name|mode=54580004, usn