我有一个Oracle DB软件包,该软件包通常会导致我认为是ITL(感兴趣的事务列表)的死锁。跟踪文件的相关部分如下。

Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TM-0000cb52-00000000        22     131           S       23     143          SS
TM-0000ceec-00000000        23     143    SX             32     138    SX   SSX
TM-0000cb52-00000000        30     138    SX             22     131           S
session 131: DID 0001-0016-00000D1C session 143: DID 0001-0017-000055D5
session 143: DID 0001-0017-000055D5 session 138: DID 0001-001E-000067A0
session 138: DID 0001-001E-000067A0 session 131: DID 0001-0016-00000D1C
Rows waited on:
Session 143: no row
Session 138: no row
Session 131: no row


该表上没有位图索引,所以这不是原因。据我所知,在Waiter waits列中缺少“ Row waited on”加上“ S”可能表明这是一个ITL僵局。此外,该表的写入频率非常高(大约同时进行8次插入或更新,每分钟多达240次),因此ITL死锁的可能性很大。

我将表的INITRANS参数及其索引增加到100,并将表上的PCT_FREE从10增加到20(然后重建索引),但是仍然发生死锁。僵局似乎最常在更新期间发生,但这可能只是一个巧合,因为我只追踪了几次。

我的问题有两个:
1)这实际上是一个ITL僵局吗?
2)如果是ITL死锁,还可以采取其他措施来避免它?



事实证明,这根本不是一个ITL死锁问题,而是一个带有未索引外键的问题。 dpbradley的回答使我发现了这一点,它使我明白了这不是ITL问题,并促使我找出了“无行”死锁的其他原因。

最佳答案

从性能角度来看,ITL压力的最佳指示是:

select event, total_waits, time_waited, average_wait
 from v$system_event
 where event like 'enq: TX%'
 order by 2 desc;


显示TX竞争等待,以及

select OBJECT_NAME, SUBOBJECT_NAME, TABLESPACE_NAME,
       OBJECT_TYPE, STATISTIC_NAME, VALUE
  from v$segment_statistics
  where statistic_name = 'ITL waits'
  and value > 0
  order by value desc;


显示涉及的表和索引。

(与所有v$视图一样,结果来自实例启动时的时间点。)

如果这表明您确实有ITL等待,则INITRANS和PCTFREE参数是要打开的主要旋钮(但是INITRANS = 100对我来说听起来很高,并且这确实占用了空间)。

如果ITL等待不是问题,则需要检查应用程序代码。

07-27 19:38