Oracle数据库 ORA-00104 错误分析和解决_oracle 死锁异常码-优快云博客

在这里插入图片描述
好的，我们来详细解析 ORA-00104 错误。这是一个相对罕见但非常重要的错误。

📌 ORA-00104 错误详解

错误信息结构组成

标准的 ORA-00104 错误信息格式如下：

ORA-00104: deadlock detected while trying to get resource resource_name

其结构可以分解为：

ORA-00104: Oracle 数据库错误的唯一标识码。
deadlock detected while trying to get resource: 错误的核心描述，表明在尝试获取一个资源时检测到了死锁。
resource_name: 一个占位符，指明了发生死锁争夺的具体资源。这通常是 Oracle 内部的资源标识符，其格式对用户不友好（如 [0xAAAA][0xBBBB],[0xCCCC]），其中包含了用于定位的十六进制地址信息。

错误含义与官方解释

官方解释：

原因 (Cause): Oracle 的后台进程（最常见的是“检测器”，但不仅限于此）在尝试获取一个内部资源时，与另一个进程（可能是用户进程，也可能是另一个后台进程）陷入了死锁状态。这个死锁被系统检测到。
行动 (Action): 这是一个内部死锁错误。请联系 Oracle 客户支持部门。通常需要提供详细的跟踪文件（trace files）和报警日志（alert log）内容以供分析。

核心要点：这是一个内部死锁错误。它不同于常见的 ORA-00060（用户事务之间的死锁）。ORA-00104 特指 Oracle 数据库自身的后台进程之间，或者在后台进程与用户进程争夺内部系统资源时发生的死锁。这表明数据库内核在管理其内部状态时遇到了一个它无法自动解决的冲突，通常意味着潜在的软件缺陷（Bug）、内存损坏或极其罕见的系统状态。

产生错误的场景与原因

典型场景：
此错误发生在数据库内部运作层面，通常与高并发、系统负载过重、或者特定的Oracle软件版本中存在的缺陷有关。普通应用程序开发人员几乎永远不会直接导致这个错误。

具体原因与示例：

Oracle 软件缺陷 (Bug)：
这是最常见的原因。特定版本的 Oracle 数据库软件中可能存在一个缺陷，在某些极其罕见的操作序列或高并发压力下，会导致两个或多个后台进程以意想不到的方式相互请求资源，从而形成死锁。例如，一个管理字典缓存的后台进程与一个管理库缓存的后台进程可能发生死锁。
内存损坏或异常：
如果数据库服务器的内存出现硬件问题（如坏内存条）、或由于操作系统问题导致 Oracle 的共享内存区（SGA）损坏，内部资源的结构可能被破坏。当后台进程尝试访问这些被破坏的资源时，可能会引发不可预知的行为，包括死锁。
极端资源争用：
在系统资源（如CPU、内存、I/O）极度饱和的情况下，进程调度可能出现异常延迟，这可能会放大某些内部操作的时间窗口，从而诱使一个在正常情况下不会发生的死锁场景出现。

特性	ORA-00060 (用户死锁)	ORA-00104 (内部死锁)
参与者	用户会话（Session）和事务（Transaction）	Oracle 后台进程或内部函数
争夺资源	表行上的锁（TX锁）	内部内存结构（闩锁等）
可恢复性	数据库自动选择一个事务回滚，其他事务继续	严重错误，可能导致进程终止或实例不稳定
频率	相对常见，由应用逻辑引起	极其罕见，通常指向底层问题
解决方法	优化应用逻辑，缩短事务	需要Oracle支持，可能需打补丁或升级

问题定位与诊断分析

当遇到 ORA-00104 时，诊断严重依赖于 Oracle 支持。DBA 需要收集信息以供分析。

诊断步骤：

检查警报日志 (Alert Log)：
这是最重要的第一步。警报日志会记录错误的发生时间、相关的进程ID（PID）和详细的跟踪文件路径。
```
# 定位警报日志位置
SQL> SELECT value FROM v$diag_info WHERE name = 'Diag Trace';
# 通常警报日志文件名为 alert_<SID>.log
```
收集跟踪文件 (Trace Files)：
错误信息中通常会指明一个或多个跟踪文件。这些文件包含了错误发生时的堆栈跟踪（stack trace）、内存转储和进程状态，是 Oracle 支持工程师分析问题的关键。
记录操作系统和时间点：
记录错误发生的精确时间、数据库版本（包括精确的版本号，如 19.15.0.0.0）、操作系统版本和硬件平台。
检查最近变更：
检查最近是否进行了系统变更，如操作系统或数据库升级、应用部署、硬件更改等。

解决方案与步骤

重要警告：ORA-00104 是一个严重的内部错误。不要试图自行修复。解决方案通常需要 Oracle 全球客户支持（My Oracle Support）的介入。

步骤：

立即行动（信息收集）：
- 不要重启数据库（除非完全宕机），以便保留错误状态。
- 立即从警报日志和跟踪文件中收集所有与错误相关的信息。
- 尝试在 My Oracle Support 上使用 ORA-00104 和跟踪文件中的关键信息进行搜索，查看是否有已知的 Bug 和解决方案。
联系 Oracle 支持：
- 向 Oracle 开一个服务请求（Service Request, SR）。
- 提供所有收集到的信息：数据库版本、OS版本、警报日志片段、完整的跟踪文件。
- 遵循支持工程师的指导。他们可能会让你应用一个特定的补丁（One-Off Patch）或执行某些诊断命令。
可能的最终解决方案：
- 应用补丁：最常见的解决方案。Oracle 支持会提供一个修复已知内部死锁缺陷的补丁。
- 升级数据库：如果当前版本存在大量已知问题，可能会建议升级到一个更稳定的版本。
- 调整参数：在极少数情况下，可能有一个隐藏参数可以绕过有问题的代码路径。这必须由 Oracle 支持指导进行，切勿自行设置隐藏参数。
- 实例重启：作为临时措施，重启实例可能会清除导致错误的异常内部状态。但这不能解决根本问题，错误很可能再次出现。

通俗易懂的解释

想象一下数据库是一个繁忙的机场控制塔。

用户事务死锁 (ORA-00060)：就像两架飞机在跑道上互不相让。一架说“你先走”，另一架也说“你先走”，结果谁都走不了。控制塔（Oracle）很容易发现这个问题，并直接命令其中一架飞机（事务）换个地方（回滚），让另一架先飞。
内部死锁 (ORA-00104)：这就严重多了。它就像是控制塔内部的两个管理员自己打起来了。比如，负责雷达的和负责无线电的通话员，他们需要共享一份飞行计划。
- 雷达员对无线电员说：“把麦克风给我，我要通知飞机。”
- 无线电员对雷达员说：“不行，你得先把飞行计划给我更新了，我才能把麦克风给你。”
  结果就是：两个人都在等对方先行动，整个控制塔的运作就卡死了。控制塔系统检测到这个内部僵局，拉响了最高级别的警报：“错误！(ORA-00104) 在尝试获取‘麦克风’资源时检测到内部死锁！”

为什么这个问题严重？
因为控制塔的管理员（后台进程）本应是协作解决问题的，现在他们自己成了问题。这意味着控制塔本身的管理规则（Oracle软件代码）可能出了纰漏，或者某个设备（内存）出了故障。

所以，解决办法就是：
立即打电话给控制塔的设计制造商（Oracle支持），把黑匣子录音（跟踪文件）和塔台日志（警报日志）发给他们。他们的工程师会分析是哪个操作步骤导致了管理员吵架，然后给你提供一个修复程序（补丁），或者告诉你升级到一个新的、没这个问题的塔台系统版本。

你作为机场经理（DBA），自己是修不了这个深层设计问题的。