ORA-00600报错时切勿重启MRP或实例，应优先保留mrp_*.trc和alert_.log；核心诊断依据是方括号内第一个参数（如[kcbzib_kcrsds_1]）、MODULE NAME:(MRP0)及版本+平台+Data Guard环境，三者缺一不可。
MRP进程报ORA-00600，先别停它
MRP（Managed Recovery Process）在12c物理备库中负责应用归档日志，一旦它因ORA-00600崩溃，备库会立即停止同步，但**强行重启MRP或重启实例反而可能丢失关键诊断现场**。错误发生后，MRP通常会退出并写入trace文件，此时应优先保全：$ORACLE_BASE/diag/rdbms/<dbname>/<instancename>/trace/</instancename></dbname>下最新生成的mrp_*.trc和alert_<sid>.log</sid>。不要执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL后再重开——这会让当前未应用的日志位置、SCN状态、内存堆栈全部清空。
从alert.log里抠出第一个参数和模块名
ORA-00600本身不说明问题，真正能定位Bug的是方括号里的第一个参数（如[kcbzib_kcrsds_1]）和紧邻的模块上下文。打开alert_<sid>.log</sid>，搜索错误时间点前后3分钟，找到完整行，例如：
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [0x000000000], [0x000000000], [], [], [], [], [], [], [], [], [] *** MODULE NAME:(MRP0) *** *** SERVICE NAME:(SYS$BACKGROUND) ***
这里[kcbzib_kcrsds_1]是核心线索，MRP0确认是MRP进程触发，而非前台会话。常见MRP相关参数还有[krsv_mrp_wait]（等待超时逻辑缺陷）、[krsb_rfs_check]（RFS与MRP通信校验失败），不同参数指向完全不同的补丁路径。
查MOS时必须带齐三个要素：参数+版本+平台
在My Oracle Support（MOS）搜索时，只输[kcbzib_kcrsds_1]会返回上百条结果，必须组合过滤：
- 数据库版本精确到小版本，例如
12.1.0.2.190716（注意不是笼统写“12.1.0.2”） - 操作系统平台，如
Linux x86-64，AIX或Windows上的同一参数可能对应不同Bug - 是否为Data Guard环境（必须勾选“Data Guard”产品分类）
例如Bug 27923296在12.1.0.2.180717 PSU中修复，但若你打的是12.1.0.2.190115 RU，则该补丁未必包含。用opatch lsinventory -bugs_fixed | grep -i 27923296验证本地是否已含修复，比盲目升级更可靠。
临时绕过方案要避开高风险操作
若MOS确认是已知Bug且补丁尚未就绪，可考虑临时缓解，但以下操作有明确禁忌：
- 禁用实时应用（
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT）→ 改为手动应用归档，避免MRP持续触发断言 - 对报错日志涉及的数据文件，检查是否有坏块：
dbv file=/path/to/datafile.dbf；若有，用备份恢复该文件，而非运行RECOVER DATAFILE，后者可能在MRP上下文中二次触发ORA-00600 - 绝对不要在备库执行
ALTER SYSTEM CHECKPOINT或ALTER SYSTEM ARCHIVE LOG CURRENT——这些命令会强制刷新内存结构，加剧MRP内部状态不一致
最易被忽略的一点：12c备库的_disable_logging隐含参数在MRP场景下可能被误启，它会导致日志应用逻辑跳过关键校验，直接引发[kcrfw_redo_write_latch]类错误。检查SHOW PARAMETER _disable_logging，若为TRUE，立刻在spfile中设为FALSE并重启MRP（无需重启实例）。
