从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: [e-mail]
 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”，那么这是否意味着从employee表中删除记录时该表将获得表级锁定？我目前在外键列上没有索引。在此列上添加索引会有所帮助吗？

如果需要更多信息，请发表。

谢谢

Answer 1

首先，select语句永远不会锁定Oracle中的任何内容，而只会使用最后可用的一致版本的数据。这不是一个情况下select ... for update，类似的锁定数据update从Oracle 9i，但目前还没有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）锁。此会话已被会话＃24阻止，该会话＃24已经持有相同类型的表级锁（SX），并等待SSX锁可用。

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

此（第二行）演示了完全相同的情况，但方向相反：会话＃24等待SSX锁可用，但被已在同一表上持有SX锁的会话＃72阻止。

因此，会话＃24和会话＃72相互阻塞：发生死锁。

两种锁类型（SX和SSX）都是表级锁。
为了了解这种情况，我建议阅读Franck Pachot的这篇文章。

以下是本文的引文，与您的情况直接相关（请注意，SSX和SRX的缩写是等效的）：

参照完整性也获得TM锁。例如，当您在父表上发布删除或更新键时，未索引外键的常见问题导致子表上的S锁。这是因为，没有索引，Oracle就没有单个较低级别的资源可以锁定，以防止并发插入会违反参照完整性。
当外键列是常规索引中的前导列时，则具有父值的第一个索引条目可以用作单个资源，并用行级TX锁进行锁定。
如果参照完整性具有on Delete级联，该怎么办？除了S模式外，还打算像X行（RX）模式一样更新子表中的行。这是共享行独占（SRX）发生的位置：S + RX = SRX。

因此，最可能的变体是会话＃72和会话＃24会同时删除EMPLOYEE表中的某些行，并且存在on delete cascade约束，并且该表首先列出的列EMPSAL_EMP_ID没有索引。EMPLOYEE_SALARYEMPSAL_EMP_ID