从 oracle 跟踪文件中查找死锁错误的原因

Question

当多个用户使用该应用程序时，我现在经常在我的应用程序中收到此“在等待资源时检测到 ora-00060 死锁”错误。我从 oracle 管理员那里得到了跟踪文件，但在阅读它时需要帮助。以下是跟踪文件中的一些数据，希望对找出原因有所帮助。

*** 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”，那么是不是表示在从employee表中删除记录时，该表获得了表级锁？我目前在外键列上没有索引。在此列上添加索引会有帮助吗？

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

谢谢

Answer 1

首先，select 语句从不锁定 Oracle 中的任何内容，只使用最后可用的一致版本的数据。自 Oracle 9i 以来，select ... for update 不会锁定像 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) 锁。此会话被会话 #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 锁变为可用，但被会话 #72 阻塞，会话 #72 已经在同一张表上持有 SX 锁。

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

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

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

参照完整性也获得 TM 锁。例如，常见的 未索引外键的问题导致子表上的 S 锁 您对父表的键发出删除或更新。这是 因为没有索引，Oracle 就没有单一的较低级别的资源来 锁定以防止并发插入可能违反 参照完整性。
当外键列是前导时 常规索引中的列，然后是父项的第一个索引条目 value 可以用作单个资源并使用行级 TX 锁定 锁。
如果参照完整性有一个删除级联怎么办？在 除了 S 模式，还有更新行的意图 子表，与第 X (RX) 行模式一样。这是共享行的位置 独占 (SRX) 发生：S+RX=SRX。

因此，最可能的变体是 Session #72 和 Session #24 同时删除了EMPLOYEE 表中的一些行，并且EMPSAL_EMP_ID 存在on delete cascade 约束以及EMPLOYEE_SALARY 上没有索引EMPSAL_EMP_ID 列首先列出的表。