如何解决Oracle Data Guard主备库SCN不一致引发的同步失败

SCN不一致是同步中断的结果而非原因，需排查归档损坏、文件缺失或空间不足等底层问题；应查v$archive_gap确认日志缺口，用v$dataguard_stats的apply_lag判断真实延迟，结合alert.log定位MRP崩溃根源。

scn不一致本身不是故障原因，而是同步中断的结果；真正要解决的是背后那个让mrp停摆的底层问题——比如归档损坏、文件缺失或空间不足。

为什么不能只比current_scn就下结论

主库current_scn每秒都在涨，备库只有在日志应用完成后才会更新这个值。如果备库用的是MANAGED STANDBY（靠归档轮询应用），它的current_scn天然滞后几分钟甚至更久，这不是异常。

• 查备库RECOVERY_MODE：执行SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2，返回MANAGED STANDBY就说明延迟是设计使然
• 真要看同步状态，得查v$dataguard_stats里的apply_lag，它反映的是“时间差”，不是SCN差
• v$dataguard_stats必须在主库查；若apply_lag持续增大（如+00 00:12:33），才说明MRP没在干活

查v$archive_gap确认是否真丢了日志

这是判断同步中断根源的第一步。只要v$archive_gap有输出，说明主库生成了某段连续序号的日志，但备库RFS进程根本没收到——后续日志再全也没用，gap不填上就卡死。

• 只在备库查：SELECT * FROM v$archive_gap
• 如果有记录，记下low_sequence#和high_sequence#
• 立刻去主库执行LIST ARCHIVELOG FROM SEQUENCE <code>low_seq UNTIL SEQUENCE high_seq THREAD 1，确认这些归档是否还在主库磁盘上
• 如果存在，用scp或rsync拷到备库LOG_ARCHIVE_DEST_2指定的路径下，路径必须严格一致

MRP启动后秒退？大概率是坏归档或UNNAMED文件挡路

执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT后，ps aux | grep mrp看不到进程，或者v$managed_standby里status是NOT ACTIVE，说明MRP启动即崩溃。

• 立刻看备库alert.log最后100行：tail -100 $ORACLE_BASE/diag/rdbms/*/trace/alert_*.log
• 如果报ORA-00600: [kcbr_apply_change_11]或FILE MISSING，基本锁定是归档损坏或数据文件创建失败
• 查v$datafile，看有没有UNNAMED00xxx文件名；有就说明standby_file_management自动模式因空间/权限失败了
• 临时切手动：ALTER SYSTEM SET standby_file_management = MANUAL SCOPE=BOTH，再手动建文件或删掉UNNAMED占位符

备库checkpoint_change#和last_scn差异大，别急着重建

执行SELECT a.name, a.checkpoint_change# "start_SCN", b.checkpoint_change# "last_SCN" FROM v$datafile_header a, v$datafile b WHERE a.file# = b.file#，发现差值很大，不代表数据损坏，只说明该文件头还没被MRP刷过。

• 这种差异常见于MRP长期未运行，或某个数据文件从没被重做流覆盖过
• 优先检查v$recover_file是否有FILE MISSING；有就先处理文件，而不是刷SCN
• 强行用RECOVER DATABASE UNTIL SCN xxx可能跳过关键变更，风险极高
• 最稳妥做法：确认归档完整、MRP能稳定运行后，让它自己把SCN拉平

SCN数值本身没有修复操作，所有“SCN不一致”的告警，最终都要落到具体文件、具体归档、具体进程状态上去验证——盯着数字看，不如打开alert.log翻三行。