Oracle 11g物理备库遇无效归档（STATUS为X/D、文件损坏或为空）时，MRP0进程卡住且FAL无法自动修复；需先查V$ARCHIVED_LOG确认状态，再用cksum/md5sum比对主备哈希值验证损坏，严禁在备库执行CROSSCHECK，所有归档管理应由主库统一控制。
oracle 11g物理备库收到无效归档（比如校验失败、损坏、或被误删后残留空文件）时，mrp0进程会卡住并报错，常见现象是ora-00334、ora-00310或ora-19505，同时v$archive_gap可能查不到 gap，但v$archived_log里对应日志的status为x（expired）或d（deleted），is_recovery_dest_file为no。这种情况下不能靠 fal 自动拉取——fal 只认“缺失”，不识别“存在但无效”。必须人工干预。
怎么确认归档确实无效而不是只是没传过来
先别急着拷文件。在备库上执行：
SELECT THREAD#, SEQUENCE#, NAME, STATUS, IS_RECOVERY_DEST_FILE FROM V$ARCHIVED_LOG WHERE FIRST_TIME > SYSDATE - 1 ORDER BY SEQUENCE# DESC;
重点关注STATUS字段：A（Available）才是可用；X或D说明 RMAN 已标记为失效；若NAME路径下文件实际存在但大小为 0 或 file 命令显示“data”类型异常，就是典型无效归档。再用cksum或md5sum比对主备两端同名归档（如arch_1_12345.arc）的哈希值，不一致即确认损坏。
主库重新生成并发送归档的实操步骤
适用于主库仍保留原始归档且未被RMAN DELETE INPUT清理掉的场景。核心是让主库重做一遍归档传输动作：
- 在主库上强制归档切换一次：
ALTER SYSTEM ARCHIVE LOG CURRENT; - 确认新归档已写入本地目的地：
SELECT NAME FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE THREAD# = 1); - 手动触发归档传输：执行
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;再=ENABLE，或直接调用DBMS_SCHEDULER.CREATE_JOB跑一次ALTER SYSTEM ARCHIVE LOG CURRENT，逼迫 ARCn 进程重传最近几个序号 - 检查备库
ALERT日志是否出现RFS[?]: Archived Log Added，而非ORA-19505
手动下载+注册归档的注意事项
当主库归档已被清理，但备份中还有（如BACKUP ARCHIVELOG ALL存在），就得手工恢复。关键不是“拷过去就完事”，而是绕过 RMAN catalog 直接注册到控制文件：
- 从备份中还原指定归档（例如用
RMAN TARGET /连接主库，运行RESTORE ARCHIVELOG FROM TIME 'SYSDATE-2' UNTIL TIME 'SYSDATE-1';），输出到临时目录 - 用
scp把文件拷到备库归档目标路径（如/u01/arch/），确保权限为oracle:oinstall、权限644 - 在备库 SQL*Plus 中逐个注册：
ALTER DATABASE REGISTER OR REPLACE PHYSICAL LOGFILE '/u01/arch/arch_1_12345.arc';—— 必须加OR REPLACE PHYSICAL，否则遇到已存在记录会报ORA-16013 - 注册后立刻查
V$ARCHIVED_LOG，确认STATUS变为A且APPLIED为NO，再启动RECOVER MANAGED STANDBY DATABASE DISCONNECT
为什么crosscheck archivelog all在备库不管用
很多人习惯在备库 RMAN 中运行CROSSCHECK ARCHIVELOG ALL，指望它自动清理无效条目——但 Oracle 11g 物理备库的 RMAN 不维护归档日志的物理存在性校验逻辑，该命令只更新RC_ARCHIVED_LOG视图状态，不会触发文件系统级验证。更糟的是，它可能把本应保留的归档误标为EXPIRED。真正有效的做法是：不在备库 RMAN 中执行任何CROSSCHECK或DELETE操作，所有归档生命周期管理必须由主库统一控制，备库只负责接收和应用。
最易被忽略的一点：如果归档无效是因主库用了LOG_ARCHIVE_DEST_n的DELAY属性，而延迟期间主库归档被清理，那即使你手动补上归档，MRP0 仍可能拒绝应用——因为控制文件里记录的NEXT_CHANGE#已跳过该段。此时必须用RECOVER DATABASE UNTIL CHANGE 配合增量备份，而不是单纯补日志。
