1、故障描述

某日7.30 左右，数据库二节点突发异常宕机。此时业务系统正处于日常低峰时段，数据请求通过集群机制自动切换至其他正常节点，核心业务流程(如交易处理、数据查询等)未出现中断，用户操作界面未反馈任何报错信息，业务连续性未受影响。

某日7:32，数据库内置的状态监测模块检测到二节点实例异常终止状态，立即触发自动恢复程序。系统依次完成进程重启(包括数据库实例、监听服务等核心组件)、会话状态同步(将宕机前未完成的轻量级事务日志同步至内存)、数据一致性校验(通过 SMON 进程验证关键数据文件与日志文件的完整性)等操作，二节点数据库成功自动拉起。此时查看数据库监控面板，连接数、CPU 占用率、I/O 响应时间等关键指标已恢复至正常阈值，节点状态显示为 “正常运行”。

某日9:40，深入(alert.log、集群后台进程日志等)进行溯源分析，发现宕机时刻存在实例通信超时、进程异常退出的特征记录。通过将日志信息与 My Oracle Support(MOS)数据库中的 bug 库进行比对，确认此次异常由 Oracle 某特定版本数据库的已知 bug 导致，从而引发实例短暂宕机后自动恢复，与本次事件的时间节点、现象特征完全匹配。目前已记录该 bug 编号及对应修复方案，后续将在测试环境验证补丁兼容性，计划在业务低峰期实施修复，避免同类故障再次发生。

2、根因分析

进一步核对日志细节发现，实例驱逐过程中，LMON 进程记录的驱逐原因码0x2对应 Oracle 内部定义的 “资源 Ticket超时” 场景，与 MOS 文档中该 bug 描述的 “因流控制 Ticket分配异常导致节点间通信超时，触发集群健康检查机制主动驱逐实例” 特征完全吻合。同时，PMON 进程终止实例时抛出的ORA-00481: LMON process terminated with error错误，正是该 bug 在实例级的典型报错表现 —— 此错误通常因 LMON 进程(负责集群锁管理与节点监控)异常退出，PMON 触发实例自我保护机制所致。上述日志特征与 MOS 文档中该 bug 的错误链( Ticket异常→LMON 故障→PMON 终止实例)完全匹配，进一步验证了故障根因为目标 bug。

3、解决方案

(1)、测试环境细节：测试环境需严格复刻生产的关键配置，包括操作系统版本、内核参数、Oracle 集群软件版本(如 GI 版本)、网络拓扑(私有网络带宽、延迟)、存储配置(ASM 磁盘组布局、I/O 性能)等，确保补丁在一致的底层环境中验证。

(2)、补丁测试逻辑：先在测试环境的二节点集群中部署 15 版本 PSU，再单独应用 12 版本 PSU 对应的目标 bug 补丁(需确认该补丁与 15 版本 PSU 的依赖关系，避免因版本冲突导致补丁应用失败)。持续监控集群日志(alert.log、cssd.log、lmon.trc)，观察是否再出现实例驱逐、LMON/PMON 异常等现象，以此判断兼容性。

(3)、补丁应用策略：若兼容，后续选择业务低峰期(如深夜)，采用 RAC 滚动补丁方式，先对集群中一个节点停业务、打补丁、重启实例验证，确认无异常后再对另一节点操作，全程监控应用连接切换与业务连续性，避免双节点同时离线;若不兼容：先在测试环境验证补丁回退至 12 版本 PSU 的可行性(需确认回退路径是否支持从 15 直接回退至 12，避免因版本跨度导致回退失败)，生产环境回退时同样采用滚动方式，每个节点回退后需通过健康检查(如 crsctl check cluster、业务功能抽样验证)，再进行下一节点操作，降低回退风险。

(4)、过程记录与复盘：测试及补丁应用全程需记录关键操作步骤、日志输出、业务验证结果，形成文档。若出现兼容性问题，需分析具体报错信息(如补丁冲突提示、进程异常日志)，同步反馈至 Oracle 支持团队确认解决方案，确保最终补丁方案兼具安全性与有效性。