デッドロックグラフで質問を更新できれば、それは有用な情報になります。 （アプリケーションでデッドロックが発生すると、OracleはORA-00060を発生させ、トレースファイルがuser_dump_destに書き込まれます。）トレースファイルを見ると、「デッドロックグラフ」というセクションがあります。それを投稿でき、デッドロックの原因となったステートメントやデッドロックに関連するその他のステートメントも投稿できれば、いくつかの結論を導き出すことができます。 （私が要求したすべての情報は、トレースファイルで入手できます。）
Alessandroが述べたように、親子関係の子テーブルにあるインデックス付けされていない外部キーが原因で、同じテーブル内の異なる行をロックしているセッションがデッドロックする可能性があります。また、テーブルにITLエントリが不足している場合など、テーブルが親子関係の一部でなくても、同じテーブルの異なる行を更新する2つのセッションでデッドロックが発生する可能性があります。
繰り返しになりますが、上記でリクエストされた情報を投稿してください。デッドロックの根本的な原因を特定できると確信しています。
2012年7月30日に追加**
以下を追加すると、デッドロックトレースファイルが提供されます。まず、トレースファイルの内容に基づいて、これは、ロックしようとしている行でセッションがオーバーラップ/衝突するための単純なデッドロックです。デッドロックが異なるであるという以前のコメントにもかかわらず 行、この特定のデッドロックは、同じの行レベルのロックが原因であることをお伝えします。 行。
デッドロックグラフがロックが保持されているモードが「X」（排他的）であり、ロックが待機しているモードが「X」であることを示しているという事実は、これが単純な行レベルのロックであることを示しています。
この場合、SID20は「RPT_TABLE.TEMP_TABLE_T1から削除します。ここでTEMP_T1_ID=：1」を実行しており、すでに ROWIDAAAPDIAAMAAAEfIAAAのロック。
その間、SID 790は「RPT_TABLE.T1_UPDATE_StoredProc」を実行していますが、すでにROWIDAAAPDIAAMAAAEfGAAAのロックを保持しています。
トレースファイルの「待機中の行」セクションから、SID20はSID790が保持している行で待機しており、SID790はSID20が保持している行で待機していることに注意してください。これは古典的なデッドロックです。
いくつかの追加情報：
-
エンキュータイプはTX（デッドロックグラフを参照）であるため、これは間違いなくではありません。 インデックス付けされていない外部キーによるロック。インデックス付けされていないFKが原因でロックされていた場合、エンキュータイプはTXではなくTMになります。 （TMエンキューが関与するケースは他に少なくとも1つあり、インデックス付けされていないFKではありません。したがって、TMエンキューが常にインデックス付けされていないFKを意味するとは限りません。）
-
ロックが待機しているモードは「X」（排他的）であるため、これは行レベルのロックです。待機しているモードが「S」（共有）の場合、ではありません。 行レベルのロックになります。むしろ、ITL不足、PKまたは英国の執行である可能性があります。
お役に立てば幸いです。