scn差距过大是同步失败的结果而非原因，真正导致卡死的是数据文件头与控制文件scn不一致引发ora-10458等错误；mrp0状态显示applying_log但sequence#长期不动，表明日志应用停滞。
SCN差距过大不是同步失败的原因，而是同步失败的结果
主备库CURRENT_SCN差值上百万甚至上千万，本身不触发报错；真正导致同步卡死的是底层数据文件头与控制文件的SCN不一致，引发ORA-10458或ORA-01152等错误。此时V$MANAGED_STANDBY中MRP0状态可能显示APPLYING_LOG，但SEQUENCE#长期不动——说明它正卡在某个日志应用环节，无法推进SCN。
为什么SCN差距会越拉越大
差距扩大本质是“应用停滞 → SCN冻结 → 新日志持续生成 → 差距滚雪球”。常见诱因包括：
-
V$ARCHIVE_GAP非空，但FAL（Fetch Archive Log）机制失效：备库没收到某段归档，MRP0不会跳过，直接挂起 - 新增
DATAFILE未同步：主库加了+DATADG1/myfile.dbf，备库ASM里无对应路径，MRP0静默停住，不报错也不推进 -
STANDBY_FILE_MANAGEMENT=MANUAL：遇到新数据文件自动创建失败，生成UNNAMED文件，MRP0立即停止 - 归档传输配置错误：
LOG_ARCHIVE_DEST_2缺VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，RAC主库切换角色后归档断流
查SCN差距不能只看CURRENT_SCN
备库CURRENT_SCN在未启用实时应用时天然滞后，V$DATABASE.CURRENT_SCN只在日志应用完成后才更新。直接比这个值会误判。
更准的做法是交叉验证：
- 主库执行
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL - 备库执行同样语句，再查
V$MANAGED_STANDBY中MRP0正在处理的SEQUENCE#对应日志的FIRST_CHANGE#（从V$ARCHIVED_LOG查） - 若备库SCN远小于该
FIRST_CHANGE#，说明连归档都没开始应用，差距根源在传输层
修复前必须确认的三件事
别急着跑RECOVER命令，先堵住源头：
- 查
V$ARCHIVE_DEST_STATUS中DEST_ID=2的ERROR字段：常见ORA-12541: TNS:no listener或ORA-27040: file create error（归档路径不可写） - 确认
LOG_ARCHIVE_DEST_2是否含SYNC/AFFIRM且网络稳定：设LGWR SYNC AFFIRM但网络抖动，LNS进程会BLOCK主库提交 - 检查备库
STANDBY_FILE_MANAGEMENT是否为AUTO：手动管理下新增表空间极易漏建数据文件
SCN差距本身不可怕，可怕的是把它当病因去调。真正要盯的是MRP0是否真在跑、归档是否真传到、数据文件是否存在且可写——这些才是让SCN动起来的前提。一旦其中一环断开，SCN就会永远停在某个点，越积越多。
