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

作者：袖梨 2026-06-24

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刷过。