ora-600在物理备库归档应用阶段报错大概率非数据损坏，而是11.2.0.4等老版本psu缺失导致的mrp进程内存/日志解析缺陷，需先查v$managed_standby确认mrp状态，再结合alert.log中[krsu_apply_arc]等函数名定位，并优先应用补丁27923157修复。
ora-600在物理备库归档应用阶段报错，大概率不是数据损坏，而是11.2.0.4等老版本中已知的psu缺失导致的内存/日志解析缺陷
ORA-600报错发生在MRP进程应用归档时，先查MRP状态和v$managed_standby
物理备库上ORA-600常伴随MRP（Managed Recovery Process）异常中断，而不是数据库无法启动。别急着调SCN或重建索引，先确认是不是MRP自己崩了：
- 执行
SELECT process, status, sequence#, thread# FROM v$managed_standby;，看MRP是否为APPLYING_LOG或已变成UNKNOWN - 检查
alert.log里最近几条MRP相关的错误行，重点关注带[krsu_apply_arc]、[krsh_apply_log]或[ksfd]这类内部函数名的ORA-600参数 - 如果
MRP反复重启、日志里出现terminating the instance due to error 600，基本可排除主库归档损坏，指向备库自身处理逻辑缺陷
ORA-600[4194]/[4193]在备库出现，大概率是undo元数据校验失败，而非真实undo损坏
很多DBA看到ORA-600[4194]就立刻切undo_management=manual，但在DG环境这是高风险操作。11.2.0.4下该错误常因MRP在解析主库传来的归档时，对undo segment header的校验逻辑存在竞态条件——尤其当主库做了大量并行DML后传到备库。
- 该问题在
Oracle 11.2.0.4.180717及之后的PSU中被修复（Patch 27923157等），补丁修正了kcbz_check_objd_typ函数在校验undo block时未正确处理备库只读上下文的场景 - 不要手动重建
UNDOTBS1或切换到SYSTEM回滚段——这会导致后续应用归档时因undo元数据不一致而二次报错 - 验证方式：在备库执行
SELECT * FROM v$rollname WHERE usn ，若返回正常且无<code>INVALID状态，说明undo结构本身完好
跳过补丁直接改参数是饮鸩止渴，_allow_resetlogs_corruption在DG备库完全无效
物理备库没有RESETLOGS机会，alter system set "_allow_resetlogs_corruption"=true这类隐藏参数对MRP进程无影响，还可能污染spfile导致后续升级失败。
- 强行设置
undo_management=manual会让MRP跳过undo校验，但应用到含DDL或事务拆分的归档时，必然在SMON清理阶段触发ORA-600[13013]或ORA-00607 - 真正有效的临时规避是停MRP、清空
standby_redo_logs、再启MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;→ 删除所有standby log文件 →ALTER DATABASE ADD STANDBY LOGFILE ...→ 重新启动MRP - 但这只是把问题延迟——只要没打PSU，下次遇到相同归档序列仍会复现
验证PSU是否生效，关键看opatch lsinventory输出里的Database PSU时间戳
打完PSU后不能只看opatch lsinventory有没有显示补丁号，要确认它是否实际加载进实例：
- 执行
$ORACLE_HOME/OPatch/opatch lsinventory -bugs_fixed | grep -i "600\|4194\|4193"，应看到类似27923157: ORA-600 [4194] ON PHYSICAL STANDBY DURING ARCHIVE APPLY - 连接备库执行
SELECT banner FROM v$version;，确保版本字符串末尾显示11.2.0.4.0之后还有PSU字样（如11.2.0.4.180717） - 最直接验证：停MRP后手动
RECOVER STANDBY DATABASE应用一个之前必报错的归档，成功即说明补丁生效
补丁不是万能解药，但对11g物理备库的ORA-600，漏掉PSU是最常被忽略的根因——它藏在opatch输出里，不在alert日志中显式提示。
