【真实经验分享】ORA-03113 ORA-7445[evaopn3()+240]根因定位：从通信中断到内核空指针崩溃的完整排查实录
ORA-03113 ORA-7445[evaopn3()+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-7445[evaopn3()+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 的重现场景必须同时满足：
- ORA-7445发生在聚合求值函数中（包括
evaopn3） - ORDER BY 消除（Order By Elimination, OBE）被执行
- 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）
ALTERSESSIONSET"_optimizer_order_by_elimination_enabled"=FALSE;优点：会话级别关闭触发 Bug 的优化特性。
缺点：需要修改应用代码（代码层面不一定支持），比较麻烦，被客户否决。
方案二：使用 Hint 锁定执行计划
在排障过程中发现，该SQL语句有时候是能执行成功，然后对比了执行计划，加上以下hint后就能运行成功。
SELECT/*+ USE_HASH(t1 t2) */...原理：
- Bug 的触发与执行计划强相关，特定 Join 顺序和访问路径会触发 OBE 优化中的缺陷
- 通过
USE_HASHHint强制使用 Hash Join，改变 CBO 生成的执行计划 - 新的执行计划不再触发 ORDER BY Elimination 的缺陷路径，从而绕开 Bug
优点：
- 无需修改数据库参数，无需打补丁
- 只影响特定 SQL，不影响全局
- 立即验证，立即可用
缺点：需要修改应用代码，比较麻烦，被客户否决。
方案三：应用官方 Patch 12672969
优点：官方修复，彻底解决问题。
缺点： 需要维护窗口，生产环境打补丁存在一定的风险。
该数据库是在虚拟机上，后来复制了一个虚拟机的镜像，做了补丁测试，这样就可以将风险降到最低。之后在生产环境上打了补丁后，问题得到解决。