【真实经验分享】ORA-03113 ORA-7445[evaopn3()+240]根因定位：从通信中断到内核空指针崩溃的完整排查实录

ORA-03113 ORA-7445evaopn3()+240 根因定位：从通信中断到内核空指针崩溃的完整排查实录

版本环境 ：Oracle 11.2.0.1.0 (64bit) on Windows Server 2012

问题现象 ：客户端偶发 ORA-03113 "通信通道的文件结尾"，服务端进程崩溃

根本原因 ：Oracle Bug 12672969 --- ORDER BY 消除优化导致 evaopn3() 空指针解引用

解决方案：打补丁解决BUG问题。

---

一、问题现象：客户端"失联"

某客户的业务系统前端，偶发报错：

ORA-03113: 通信通道的文件结尾

客户端表现为"无法从套接字读取更多数据"，SQL 执行到一半突然中断。起初以为是网络不稳定，但排查alert日志后发现，ORA-03113之后都伴随ORA-7445evaopn3()+240。

这说明问题不在网络，而在是BUG导致的。

---

二、服务端追踪：ORA-7445 内核崩溃

对 Alert Log 和 Trace 文件中ORA-7445信息进行分析：

Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x4] [PC:0x2C26DB6, evaopn3()+240]
ORA-07445: exception encountered: core dump [evaopn3()+240] [ACCESS_VIOLATION] [ADDR:0x4]

2.1 关键信息解读

字段	含义
ACCESS_VIOLATION	访问违规，即空指针/野指针解引用
ADDR:0x4	试图读取地址 0x0000000000000004，典型的空结构体偏移访问
PC:0x2C26DB6	程序计数器指向 evaopn3()+240
evaopn3()	Oracle 内核函数，负责表达式求值（Expression Evaluation）

2.2 Call Stack 分析

从堆栈可以看到崩溃前的调用链：

evaopn3()+240
  → qerixTunnelGetKey()+1599
    → qerixStart()+1844
      → qertbStart()+1036
        → qerjoStart()+542  (多次，说明有多个 JOIN 操作)
          → qergsStart()+868  (Group By / Sort 操作)
            → qerjoFetch()/qerflFetch()  (数据获取)
              → opifch2()  (最终返回客户端)

关键特征：

• 崩溃发生在 evaopn3() 表达式求值阶段
• 调用链中包含 qergsStart（Group By/Sort）和多次 qerjoStart（Join）
• 这是一个复杂的多表 JOIN + 聚合查询

---

三、根因定位：Oracle Bug 12672969

3.1 匹配官方 Bug

根据 MOS（My Oracle Support）文档，该症状与 Bug 12672969 高度吻合：

Bug 12672969 --- Assorted Dumps with aggregate expression in ORDER BY

影响版本：11.2.0.1 ~ 11.2.0.3（低于 12.1）

症状：包含 ORDER BY 子句且其中带有聚合函数的查询可能触发 ORA-7445 evaopn3

3.2 Bug 触发条件

根据 MOS 文档，该 Bug 的重现场景必须同时满足：

1. ORA-7445 发生在聚合求值函数中（包括 evaopn3）
2. ORDER BY 消除（Order By Elimination, OBE） 被执行
3. ORDER BY 子句中存在聚合函数位于操作符树中间

3.3 本案例的触发路径

查看了出问题的SQL语句，发现与BUG有以下雷同之处：

• 查询涉及多表 LEFT JOIN
• 包含 GROUP BY / ORDER BY 操作
• CBO 在执行 ORDER BY Elimination 优化转换时，对包含聚合表达式的 ORDER BY 子句处理不当

可以基本确定是这个BUG引起的。

3.4故障发生链

客户端报 ORA-03113 只是表象。根本原因是：

服务端进程因 ORA-7445 崩溃 → 操作系统终止 ORACLE.EXE 进程 → TCP 连接被强制断开 → 客户端读取套接字失败 → 抛出 ORA-03113

---

四、解决方案对比

方案一：禁用 ORDER BY 消除（官方 Workaround）

ALTER SESSION SET "_optimizer_order_by_elimination_enabled" = FALSE;

优点 ：会话级别关闭触发 Bug 的优化特性。

缺点：需要修改应用代码（代码层面不一定支持），比较麻烦，被客户否决。

方案二：使用 Hint 锁定执行计划

在排障过程中发现，该SQL语句有时候是能执行成功，然后对比了执行计划，加上以下hint后就能运行成功。

SELECT /*+ USE_HASH(t1 t2) */ ...

原理：

• Bug 的触发与执行计划强相关，特定 Join 顺序和访问路径会触发 OBE 优化中的缺陷
• 通过 USE_HASH Hint 强制使用 Hash Join，改变 CBO 生成的执行计划
• 新的执行计划不再触发 ORDER BY Elimination 的缺陷路径，从而绕开 Bug

优点：

• 无需修改数据库参数，无需打补丁
• 只影响特定 SQL，不影响全局
• 立即验证，立即可用

缺点：需要修改应用代码，比较麻烦，被客户否决。

方案三：应用官方 Patch 12672969

优点 ：官方修复，彻底解决问题。

缺点： 需要维护窗口，生产环境打补丁存在一定的风险。

该数据库是在虚拟机上，后来复制了一个虚拟机的镜像，做了补丁测试，这样就可以将风险降到最低。之后在生产环境上打了补丁后，问题得到解决。