我有一个 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 列中缺少“Rows waiting 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 等待不是问题，则需要检查应用程序代码。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
