Oracleトレース・ファイルのデッドロック・エラーの原因の特定

Question

複数のユーザーがアプリケーションを使用しているときに、アプリケーションでこの「ora-00060デッドロックが検出されました」というエラーが頻繁に発生しました。私はoracle Adminからトレースファイルを入手しましたが、それを読むのに助けが必要です。以下は、トレースファイルからのデータのビットです。原因の特定に役立ちます。

*** 2013-06-25 09:37:35.324 
DEADLOCK DETECTED (ORA-00060) 

[Transaction Deadlock] 

The following deadlock is not an ORACLE error. It is a deadlock due 
to user error in the design of an application 
or from issuing incorrect ad-hoc SQL. The following 
information may aid in determining the deadlock: 

Deadlock graph: 
        ---------Blocker(s)-------- ---------Waiter(s)--------- 
Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  210  72 SX SSX  208  24 SX SSX 
TM-000151a2-00000000  208  24 SX SSX  210  72 SX SSX 

session 72: DID 0001-00D2-000000C6 session 24: DID 0001-00D0-00000043 
session 24: DID 0001-00D0-00000043 session 72: DID 0001-00D2-000000C6 

Rows waited on: 
Session 72: no row 
Session 24: no row 

----- Information for the OTHER waiting sessions ----- 
Session 24: 
sid: 24 ser: 45245 audsid: 31660323 user: 90/USER 
    flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/- 
    flags2: (0x40009) -/-/INC 
pid: 208 O/S info: user: zgrid, term: UNKNOWN, ospid: 2439 
    image: oracle@xyz.local 
client details: 
    O/S info: user: , term: , ospid: 1234 
    machine: xyz.local program: 
current SQL: 
    delete from EMPLOYEE where EMP_ID=:1 

----- End of information for the OTHER waiting sessions ----- 

Information for THIS session: 

----- Current SQL Statement for this session (sql_id=dyfg1wd8xa9qt) ----- 
delete from EMPLOYEE where EMP_ID=:1 
=================================================== 

いくつかのいずれかが「デッドロックのグラフは::」言っている私に言うことができる場合、私は幸いです。また、セクションで待機している行には行がありません。

また、一部のブログでは、トレースファイルの「sqltxt」セクションに原因を示唆するものがあります。以下はそのセクションで私が見ているクエリです。

select /*+ all_rows */ count(1) from "USERS"."EMPLOYEE_SALARY" where EMPSAL_EMP_ID=:1 

employee_salaryテーブルには、EMPSAL_EMP_IDカラムに対する外部キー制約があります。

sqlヒントには「all_rows」と表示されているため、従業員テーブルからレコードを削除するときにこのテーブルがテーブルレベルのロックを取得していますか？私は現在、外部キー列にインデックスを持っていません。この列の索引を追加すると役立つでしょうか？

これ以上の情報が必要な場合は、お知らせします。

おかげで、すべての

Answer 1

まず、select声明オラクルで何かをロックすることはありませんが、単にデータの最後に利用できる一貫したバージョンを使用しています。 select ... for updateでは、Oracle 9iからupdateのようなデータをロックしますが、質問からのクエリにはfor update句がありません。

Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  210  72 SX SSX  208  24 SX SSX 

セッション＃72「行排他」タイプ（SX）とテーブルレベルロック（TM）を保持し、「共有行排他」同じテーブル上（SSX）ロックを取得します。このセッションは、同じタイプ（SX）のテーブルレベルのロックをすでに保持しているセッション＃24によってブロックされ、SSXロックが利用可能になるまで待機します。

Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  208  24 SX SSX  210  72 SX SSX 

この（第2行）がまったく同じ状況を示すが、反対方向に：SSXのセッション＃24待つ使用可能になるロックが、すでに同じテーブル上のSXロックを保持しているセッション＃72によって遮ら。

したがって、セッション＃24とセッション＃72が互いにブロックします。デッドロックが発生します。

両方のロックタイプ（SXとSSX）は、テーブルレベルのロックです。
状況を理解するには、Franck Pachotのthis articleとお読みください。参照整合性もTMのロックを取得し

：以下

は、自分の状況に直接関連（SSXとSRX略語が等価であることに注意してください）、この記事からの引用です。たとえば、親テーブルで のキーを削除または更新すると、非インデックスの外部キーを持つ共通の の問題により、子テーブルのSロックが発生します。これは です。索引がないと、 参照整合性に違反する可能性のある同時挿入を防止するために、Oracleは単一の下位レベルのリソースを にロックしないためです。
外部キー列が通常のインデックス内の先頭の 列である場合、親の の値を持つ最初のインデックスエントリは単一のリソースとして使用でき、行レベルのTX ロックでロックできます。
参照整合性にon deleteカスケードがある場合はどうなりますか？ Sモードに加えて、Row X（RX）モードと同様に、子テーブルの の行を更新する予定があります。これは、共有行 排他的（SRX）が発生する場所です.S + RX = SRXです。

ので、最も可能性の変種は、Session＃72とセッション＃24が同時にEMPLOYEEテーブル内の一部の行を削除していることである、とEMPSAL_EMP_IDためon delete cascade制約がでEMPSAL_EMP_ID列EMPLOYEE_SALARYテーブル上のインデックスの不在と一緒にあります最初に挙げられた。