识别和解决Oracle ITL死锁

Question

我有一个Oracle数据库软件包,它经常导致我认为是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等待列中的"S"可能表明这是ITL的死锁.此外,该表经常被写入(大约8次插入或同时更新,通常每分钟240次),因此ITL死锁似乎很有可能.

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

我的问题有两方面:
1)这实际上是ITL的僵局吗？
2)如果是ITL死锁,还有什么办法可以避免它？

---

事实证明,这根本不是ITL死锁问题,而是未编入索引的外键问题.我发现这要归功于dpbradley的回答,这让我想到这不是一个ITL问题,并促使我找出导致"无行"死锁的其他原因.

Answer 1

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等待不是问题,则需要检查应用程序代码.