故障排查10 分钟阅读
Oracle 19C RAC 实例异常崩溃报错 ORA-00600 [kfmdPriRegRclient04]，一波三折！
大家好，这里是公众号 DBA学习之路，分享一些学习数据库路上的知识和经验。 @TOC目录 前文 Oracle 19C RAC 集群起不来了，ora.storage 的锅？https://www.modb.pro/db/1
2025年2月25日阅读—点赞—收藏—
oraclerac
内容阅读
在知识库中专注阅读，并随时返回相关工具与课程
大家好，这里是公众号 DBA学习之路，分享一些学习数据库路上的知识和经验。
前言
本章目标：掌握本章核心知识点 前置要求：完成前序章节学习 预计时长：60 分钟
前文 Oracle 19C RAC 集群起不来了，ora.storage 的锅？ 说到集群起不来，分析完之后发现不是集群不是实例崩溃的根因，而且集群成功启动之后，数据库实例依然 hang 住无法成功启动。
为了解决问题，我往前追溯了最开始实例崩溃的情况，本文记录一下分析和处理过程！
问题描述
首先，回顾一下问题经过，19.22 RAC 两节点，其中实例 2，在 2025-02-18T21:36:47.953581+08:00 时实例异常崩溃，在 2025-02-18T21:46:24.224088+08:00 时又自动重启。
通过实例崩溃节点的 alert 日志可以发现， 最早第一次实例崩溃的日志如下：
12025-02-18T21:36:47.953581+08:002PMON (ospid: 41879): terminating the instance due to ORA error 49932025-02-18T21:36:47.953675+08:004Cause - 'Instance is being terminated due to fatal process death (pid: 5, ospid: 41971, IPC0)'自动重启后，再次发生实例崩溃，日志如下：
12025-02-18T21:38:18.289755+08:002 Dwn-cvts replayed, VALBLKs dubious3 All grantable enqueues granted42025-02-18T21:46:23.819853+08:005Errors in file /u01/app/oracle/diag/rdbms/mesdb/mesdb2/trace/mesdb2_fenc_3353096.trc (incident=480559):6ORA-00600: internal error code, arguments: [kfmdPriRegRclient04], [], [], [], [], [], [], [], [], [], [], []7Incident details in: /u01/app/oracle/diag/rdbms/mesdb/mesdb2/incident/incdir_480559/mesdb2_fenc_3353096_i480559.trc8Use ADRCI or Support Workbench to package the incident.9See Note 411.1 at My Oracle Support for error and packaging details.102025-02-18T21:46:24.224088+08:0011Errors in file /u01/app/oracle/diag/rdbms/mesdb/mesdb2/trace/mesdb2_fenc_3353096.trc:12ORA-00600: internal error code, arguments: [kfmdPriRegRclient04], [], [], [], [], [], [], [], [], [], [], []13FENC (ospid: 3353096): terminating the instance due to ORA error 854通过上述日志可以发现，从 2025-02-18T21:38:18.289755+08:00 ～ 2025-02-18T21:46:23.819853+08:00，主要 hang 在 All grantable enqueues granted 阶段，等待了接近 8 分钟左右，然后报错 ORA-00600 [kfmdPriRegRclient04]，实例再次异常 Crashed。
关于 ORA-00600 [kfmdPriRegRclient04] 报错，大概率可能是一个 BUG，在 MOS 上搜索后发现，在当前数据库版本 19.22 有 4 个已知问题：
- ORA-600 [kfmdPriRegRclient04] ( Doc ID 2795196.1 )
- Bug 34345080 ORA-600 [kfmdpriregrclient04] - kfmdpriregrclient
- 33898768 ORA-600 [kfmdpriregrclient04] -> regression fix for bug 33781900
- 33781900 ORA-600 [kfmdpriregrclient04] With Regression fixx Also
- Bug 35469192 Instance Crashes With ORA-600 [kfmdpriregrclient04] During Reconfiguration
4 个已知问题，前 3 个已经修复在当前的数据库版本中，只有最后一个 Bug 35469192 比较符合：
1This bug is only relevant when using Real Application Clusters (RAC)2During instance start, it takes too long to complete FIXWRITE step and instance is3 killed and restarted when using Real Application Clusters (RAC)4 5 6REDISCOVERY INFORMATION:7 If ORA-600 [kfmdPriRegRclient04] is hit during instance start FIXWRITE step, 8 then this bug is encountered.910Workaround11 NONE
可以看到这个 BUG 的唯一解决方案就是 打补丁。
问题解决
补丁下载
在 MOS 上下载对应版本补丁：
正式安装补丁之前建议先阅读一下 README 文档：
- This patch is RAC Rolling Installable（注意：这是一个支持滚动安装的补丁，所以可以挨个节点进行安装）.
- Ensure that 19 Release 19.22.0.0.240116DBRU Patch Set Update (PSU) 35943157 is already applied on the Oracle Database.
- Ensure that you have OPatch 19 Release 12.2.0.1.40 or higher.
- Ensure that you shut down all the services running from the Oracle home.
- For a RAC environment, shut down all the services (database, ASM, listeners, nodeapps, and CRS daemons) running from the Oracle home of the node you want to patch.
主要关注以上几条关键信息，确保符合条件之后就可以进行补丁安装。
补丁安装
由于节点 2 数据库实例处于宕机状态，所以先在节点 2 进行补丁安装。
打补丁前建议 disable crs，防止集群自启：
1[root@mesdb2 ~]# /u01/app/19.3.0/grid/bin/crsctl disable crs2## 关闭集群3[root@mesdb2 ~]# /u01/app/19.3.0/grid/bin/crsctl stop crs -f安装补丁前校验：
1[oracle@mesdb2 35469192]$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./2Oracle Interim Patch Installer version 12.2.0.1.413Copyright (c) 2025, Oracle Corporation. All rights reserved.45PREREQ session67Oracle Home : /u01/app/oracle/product/19.3.0/db_18Central Inventory : /u01/app/oraInventory9 from : /u01/app/oracle/product/19.3.0/db_1/oraInst.loc10OPatch version : 12.2.0.1.4111OUI version : 12.2.0.7.012Log file location : /u01/app/oracle/product/19.3.0/db_1/cfgtoollogs/opatch/opatch2025-02-19_01-26-47AM_1.log1314Invoking prereq "checkconflictagainstohwithdetail"1516Prereq "checkConflictAgainstOHWithDetail" passed.1718OPatch succeeded.19[oracle@mesdb2 35469192]$确保安装前校验成功，就可以正式打补丁了：
1[oracle@mesdb2 35469192]$ opatch apply2Oracle Interim Patch Installer version 12.2.0.1.413Copyright (c) 2025, Oracle Corporation. All rights reserved.456Oracle Home : /u01/app/oracle/product/19.3.0/db_17Central Inventory : /u01/app/oraInventory8 from : /u01/app/oracle/product/19.3.0/db_1/oraInst.loc9OPatch version : 12.2.0.1.4110OUI version : 12.2.0.7.011Log file location : /u01/app/oracle/product/19.3.0/db_1/cfgtoollogs/opatch/opatch2025-02-19_01-38-43AM_1.log1213Verifying environment and performing prerequisite checks...14OPatch continues with these patches: 35469192 1516Do you want to proceed? [y|n]17y18User Responded with: Y19All checks passed.2021Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.22(Oracle Home = '/u01/app/oracle/product/19.3.0/db_1')232425Is the local system ready for patching? [y|n]26y27User Responded with: Y28Backing up files...29Applying interim patch '35469192' to OH '/u01/app/oracle/product/19.3.0/db_1'3031Patching component oracle.rdbms, 19.0.0.0.0...32Patch 35469192 successfully applied.33Log file location: /u01/app/oracle/product/19.3.0/db_1/cfgtoollogs/opatch/opatch2025-02-19_01-38-43AM_1.log3435OPatch succeeded.补丁安装成功，启动集群和数据库实例：
1[root@mesdb2 ~]# /u01/app/19.3.0/grid/bin/crsctl start crs2CRS-4123: Oracle High Availability Services has been started.3[root@mesdb2 ~]# /u01/app/19.3.0/grid/bin/crsctl enable crs不幸的是，节点 2 数据库实例依然没有启动成功，一直 hang 在 All grantable enqueues granted 阶段，但是万幸的没有再报错 ORA-00600 [kfmdPriRegRclient04]，实例也没有崩溃，说明这个 BUG 被解决了。
后续想着可能是一个节点打了一个节点没打的原因，所以在节点一上也打了补丁，结果依然是只能启动一个数据库实例：
- 节点 1 数据库实例启动成功，节点 2 数据库实例无法启动，一直 hang 在
All grantable enqueues granted阶段； - 节点 2 数据库实例启动成功，节点 1 数据库实例无法启动，一直 hang 在
All grantable enqueues granted阶段；
也就是说同时间只能启动一个数据库实例，这个问题又 hang 住了。
后续分析
基于现有信息，查了很多类似案例，基本上都是网络问题导致的。
后续查看了 OSW 问题时段的 netstat 输出中，发现了报包重组问题，比较严重：
1mesdb2_netstat_25.02.18.2100.dat2129,1: IpReasmFails 8716296 0.03596,1: IpReasmFails 8743012 0.04.......5655235,1: IpReasmFails 10667734 0.0755702,1: IpReasmFails 10725986 0.089mesdb2_netstat_25.02.18.2200.dat10129,1: IpReasmFails 10784971 0.011596,1: IpReasmFails 10843446 0.0121063,1: IpReasmFails 10902467 0.01314.......151655298,1: IpReasmFails 15147120 0.01755766,1: IpReasmFails 15200994 0.0关于这个问题，在墨天轮找到一篇相关的文章：关于Oracle RAC调整网卡MTU值的问题。
文章中给出的解决方案跟 Oracle MOS 给出的解决方案基本一致：
但是 Oracle 建议启用 Jumbo Frame，因为在 OS 版本为 Linux 8 的主机中，ipfrag 参数已经不适用。
修改 MTU
这个修改的官方主要依据：Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Doc ID 341788.1)
ifconfig 可以动态修改 MTU，但是如果 rac 想用上 mtu=9000 的话需要重启 crs（停机不可避免）：
1## 关闭 crs 集群（所有计算节点操作）2crsctl stop crs3crsctl disable crs456## 修改私有网卡 MTU 为 9000（所有节点操作）7ifconfig <网卡名称> mtu 900089## 查看 MTU 是否更改成功10ifconfig <网卡名称>1112## 修改私有网卡配置文件，添加 MTU=9000 的配置，以确保主机重启后 MTU=9000 不变13cat<<-EOF>>/etc/sysconfig/network-scripts/ifcfg-<网卡名称>14MTU=900015EOF1617## 主机重启（所有节点操作）18reboot1920## 启动 crs 集群（所有计算节点操作）21crsctl start crs22crsctl enable crs2324## 启动数据库实例25srvctl start database -d mesdb当然了，这一步修改 MTU 的操作目前还没有在生产进行操作，等待后续修改之后，再来更新一下是否有效！
写在最后
本文仅记录问题分析过程以及解决方案，请大家根据实际情况进行分辨解决方案是否有效。