根本原因是RMAN归档删除策略未对齐备库角色，应设为SHIPPED TO ALL STANDBY而非默认APPLIED ON ALL STANDBY；需检查并配置该策略、验证归档接收状态（STATUS='A'）、避免CROSSCHECK误标EXPIRED、监控MRP0真实状态及LOG_ARCHIVE_DEST_2的VALID_FOR角色匹配。
主库删归档后备库报错，根本不是“删太快”，而是rman策略没对齐备库角色
查 RMAN 归档删除策略是否设为 SHIPPED TO ALL STANDBY
Oracle 11g 默认的 APPLIED ON ALL STANDBY 策略在 ADG 场景下会误判：备库处于 READ ONLY WITH APPLY 状态时，APPLIED='YES' 不代表日志已真正写入数据文件，RMAN 却据此清理归档，导致主库还没传完、归档就没了。
- 在主库执行
RMAN TARGET /后运行：SHOW ARCHIVELOG DELETION POLICY;，输出必须是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 只反映“传输缺口”，不反映“接收但无效”。主库删了归档，备库可能已收过一个损坏/空文件，状态仍是 STATUS='X' 或 'D'，MRP0 卡死不动。
- 在备库查：
SELECT THREAD#, SEQUENCE#, NAME, STATUS, IS_RECOVERY_DEST_FILE FROM V$ARCHIVED_LOG WHERE SEQUENCE# BETWEEN <code>low_seqANDhigh_seqORDER BY SEQUENCE#; -
STATUS为A才算有效；X或D表示 RMAN 已标记失效，哪怕文件物理存在 - 用
cksum <code>full_path_to_arch对比主备同名归档哈希值——不一致即确认损坏或被截断 - 严禁在备库执行
CROSSCHECK ARCHIVELOG ALL，这会让 RMAN 主动把本地文件标为EXPIRED，雪上加霜
MRP0 静默停摆，得靠 v$managed_standby 而不是 ps 判断
进程还在，不代表它在干活。MRP0 常因遇到 UNNAMED 数据文件、控制文件时间戳异常或 undo 段问题而 halt，状态卡在 WAIT_FOR_LOG 或为空。
- 执行：
SELECT process, status, sequence#, client_process FROM v$managed_standby WHERE process = 'MRP0'; - 只有
status = 'APPLYING_LOG'或'WAIT_FOR_LOG'且sequence#持续更新才算正常 - 若无
MRP0行，说明恢复根本没启用，需手动执行：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 若有但
sequence#几分钟不变，立刻查备库alert.log，搜ORA-01111、corruption、undo
最易被忽略的点：主库 LOG_ARCHIVE_DEST_2 的 VALID_FOR 必须匹配当前角色。比如设成 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，但主库切到 SWITCHOVER 后变成 STANDBY 角色，归档传输就静默停摆——此时 v$archive_dest_status.status 会是 DEFERRED，error 字段却为空。
