ITL (Interested Transaction List) デッドロックと思われるものを日常的に引き起こしている Oracle DB パッケージがあります。トレース ファイルの関連部分を以下に示します。
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
このテーブルにはビットマップ インデックスがないため、それが原因ではありません。私が知る限り、「待機中の行」と待機列の「S」がないことは、これが ITL デッドロックであることを示している可能性があります。また、テーブルは頻繁に書き込まれるため (約 8 つの挿入または更新が同時に行われ、1 分間に 240 回も行われる)、ITL デッドロックが発生する可能性が高いようです。
テーブルの INITRANS パラメータとそのインデックスを 100 に増やし、テーブルの PCT_FREE を 10 から 20 に増やしました (その後、インデックスを再構築しました) が、デッドロックはまだ発生しています。デッドロックは更新中に最も頻繁に発生するようですが、それは偶然かもしれません。私はそれを数回追跡しただけです.
私の質問は 2 つあります
。1) これは実際に ITL デッドロックですか?
2) ITL デッドロックの場合、それを回避するために他に何ができますか?
これは ITL デッドロックの問題ではなく、インデックスのない外部キーの問題であることが判明しました。dpbradley の回答のおかげでこれを発見しました。これにより、ITL の問題ではないという事実がわかり、「行がない」デッドロックの他の原因が何であるかを調べるようになりました。