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_seqUNTIL SEQUENCEhigh_seqTHREAD 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翻三行。
