如何手动修复Oracle 12c DG中ORA-16037引起的同步无法识别

ORA-16037 是人工取消恢复的正常日志提示，非故障；真正导致同步“无法识别”的是归档断点、MRP挂起或SRL/LOG_ARCHIVE_DEST配置异常，需通过V$ARCHIVE_DEST_STATUS、V$MANAGED_STANDBY等视图精准定位。

ora-16037 不是故障，是日志应用被主动中断的正常提示；真正导致同步“无法识别”的，是它背后隐藏的归档断点或 mrps 挂起状态。

为什么 ORA-16037 总出现在备库告警日志里

这是 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL 执行后必然写入的日志记录，本身不报错、不阻塞、不损坏数据。但它常被误读为“同步失败”，实际只是上一次恢复操作被人工终止——问题出在后续没跟上 START APPLY，或者启动失败却没暴露错误。

• 查 V$ARCHIVE_DEST_STATUS 中 STATUS 是否为 VALID，ERROR 字段是否为空；非空才是真问题
• 查 V$MANAGED_STANDBY 确认 PROCESS 列中 MRP0 是否为 APPLYING_LOG；若为 WAIT_FOR_LOG 或 NOT ACTIVE，说明恢复没真正起来
• 注意：ORA-16037 单独出现时，SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG 仍可能显示大量 YES，别被它带偏方向

ORA-16037 后同步“无法识别”的真实原因

它只是个信号灯，真正让备库看起来“失联”的，往往是它掩盖下的三类断点：

• LOG_ARCHIVE_DEST_2 的 VALID_NOW 或 DELAY 参数被意外启用，导致归档不再实时推送
• 主库归档日志存在 gap（比如缺失 SEQUENCE# = 1319），MRP 启动后立刻卡住，但错误日志可能刷到 trace 文件而非 alert.log
• 备库控制文件未包含最新日志组信息（如主库新增了 GROUP 4，但备库 v$log 里查不到），MRP 尝试应用含该日志切换的归档时直接挂起，报 ORA-00313 而非 ORA-16037

手动修复步骤：从 cancel 到 apply 的闭环操作

不能只执行 CANCEL 就停，也不能只打 START APPLY 就完事。必须确认环境就绪再推进：

• 先确认备库处于 MOUNT 状态：SELECT OPEN_MODE FROM V$DATABASE 必须返回 MOUNTED
• 检查归档传输是否通畅：SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2；若 ERROR 非空，优先解决 ORA-16047 或 ORA-16057
• 确认无归档 gap：SELECT THREAD#, MIN(SEQUENCE#), MAX(SEQUENCE#) FROM V$ARCHIVED_LOG GROUP BY THREAD#，对比主备库输出是否连续
• 执行恢复命令时加 USING CURRENT LOGFILE 和 DISCONNECT：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT；否则前台会阻塞，且断开连接后进程易被 kill

容易忽略的两个硬性依赖

即使所有命令都敲对，这两点不满足，MRP 也绝不会真正跑起来：

• 备库必须有可用的 STANDBY REDO LOG（SRL），且组数 ≥ 主库在线日志组数；用 SELECT GROUP#, THREAD#, BYTES FROM V$STANDBY_LOG 查，空结果或数量不足直接导致 START APPLY 静默失败
• 主库 LOG_ARCHIVE_DEST_2 必须启用 SYNC 或 ASYNC，且不能带 NOAFFIRM（除非明确接受丢失风险）；若配置为 LGWR SYNC NOAFFIRM 但备库没 SRL，LGWR 会无限等待，最终超时并停止归档

修复不是改一个参数或敲一条命令的事。关键在确认 MRPs 进程是否真正接管日志流——盯住 V$MANAGED_STANDBY 里的 MRP0 状态，比反复看 alert.log 里的 ORA-16037 有用得多。