正确配置是SHIPPED TO ALL STANDBY，因APPLIED ON ALL STANDBY在ADG下误判READ ONLY WITH APPLY为已应用，致归档未传完即被删；需执行CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY，并验证STATUS='A'、禁用CROSSCHECK、监控MRP0真实状态。
shipped to all standby 才是主库 rman 归档删除策略的正确配置，用默认的 applied on all standby 会导致备库还没收到归档，主库就把它删了。
查 RMAN 归档删除策略是否匹配 DG 角色
主库上执行 RMAN TARGET / 后运行：SHOW ARCHIVELOG DELETION POLICY;。输出必须是 SHIPPED TO ALL STANDBY —— 这表示“只要归档已成功传到所有备库”，就允许删除；而默认的 APPLIED ON ALL STANDBY 是陷阱：它误把 ADG 备库的 READ ONLY WITH APPLY 状态当成“已应用完成”，但此时日志可能只进了内存、还没写入数据文件，RMAN 就提前清理了归档。
如果不是 SHIPPED TO ALL STANDBY，立刻执行：CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;。该配置自动同步到所有 RAC 实例（sid='*'），无需逐节点操作。
可选增强项：BACKED UP 1 TIMES TO DEVICE TYPE DISK 能防误删，但不是解决同步中断的核心条件。
确认备库是否真收到了归档，别只信 v$archive_gap
v$archive_gap 只反映“传输缺口”，不反映“接收但无效”。主库删了归档后，备库 RFS 进程可能已收过一个空文件或损坏归档，状态是 STATUS='X' 或 'D'，MRP0 会卡死不动，但 v$archive_gap 却显示“无缺口”。
在备库查：SELECT THREAD#, SEQUENCE#, NAME, STATUS, IS_RECOVERY_DEST_FILE FROM V$ARCHIVED_LOG WHERE SEQUENCE# BETWEEN <code>low_seq AND high_seq ORDER BY SEQUENCE#;
-
STATUS='A'才算有效接收 -
STATUS='X'或'D'表示 RMAN 已标记失效，哪怕文件物理存在也不能用 - 用
cksum <code>full_path_to_arch对比主备同名归档哈希值——不一致即确认损坏或被截断
严禁在备库执行 CROSSCHECK ARCHIVELOG ALL，这会让 RMAN 主动把本地文件标为 EXPIRED，雪上加霜。
MRP0 静默停摆，得靠 v$managed_standby 判断真实状态
进程还在，不代表它在干活。MRP0 常因遇到 UNNAMED 数据文件、控制文件时间戳异常或 undo 段问题而 halt，状态卡在 WAIT_FOR_LOG 或为空。
执行：SELECT process, status, sequence# FROM v$managed_standby WHERE process = 'MRP0';
- 只有
status='APPLYING_LOG'且sequence#持续递增才算正常 - 如果是
WAIT_FOR_GAP或NOT ACTIVE，说明它早就停了，不是慢，是根本没动 - 若查不到 MRP0 行，说明恢复根本没启用，需手动执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
备库报 ORA-01157 或 MRP 崩溃时，先看 alert 日志里是不是 ORA-00600
MRP 启动后立刻退出，往往不是配置问题，而是某个归档日志本身已损坏。比如 alert 日志里反复出现：ORA-00600: internal error code, arguments: [kcbr_apply_change_11]，对应归档序号从 132757 开始。
这时不能硬重启 MRP，要先清理坏归档：
- 备库 RMAN 执行：
CROSSCHECK ARCHIVELOG ALL;→DELETE NOPROMPT ARCHIVELOG FROM SEQUENCE 132757 UNTIL SEQUENCE 133169; - 主库重新传输这些归档（
scp或alter system archive log current+switch logfile） - 备库手动注册：
ALTER DATABASE REGISTER PHYSICAL LOGFILE '<code>full_path_to_arch'; - 再启动 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
最易被忽略的一点：归档路径变更、密码文件不同步、LOG_ARCHIVE_DEST_2.VALID_FOR 未随角色切换更新，都会让 RFS 进程静默失败——MRP 看不到新归档，自然无法推进。
