ORA-16014 表示归档链中断而非日志损坏，主库存在未归档在线日志但ARCn未传输；需检查归档目标可用性、FRA空间及权限，清理旧归档并验证alter system archive log current成功后方可启动MRP。
ORA-16014 是归档链断了，不是日志坏了
ORA-16014 报错出现时，主库有未归档的在线日志（比如 sequence# 187），但 ARCn 进程没把它传出去，备库自然收不到——这不是日志文件物理损坏，而是归档路径卡死。直接执行 ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP X 会跳过归档校验，让这个序列号永久消失，MRP 进程立刻报 ORA-00314 或 gap，重建备库是唯一退路。
先查归档目标是否真可用，别只看参数值
很多 DBA 看到 log_archive_dest_1 配置了路径就以为 OK，其实 OS 层面可能早断了：
-
archive log list输出里Archive destination必须是ENABLED，且Latest log sequence在持续增长 -
show parameter log_archive_dest_1查出路径后，用 Oracle OS 用户（如oracle）手动执行：ls -ld /path/to/arch和df -h /path/to/arch，确认目录存在、可写、剩余空间 ≥ 2× 当前最大单个归档大小 -
select * from v$archive_dest where dest_id = 1;看STATUS是否为VALID，ERROR列是否有内容（比如"No space left on device"）
闪回区（FRA）满是最常见根因
db_recovery_file_dest_size 不是建议值，是硬上限。一旦 v$flash_recovery_area_usage 中 ARCHIVELOG 行的 PERCENT_SPACE_USED ≥ 95% 且 PERCENT_SPACE_RECLAIMABLE = 0，ARCn 就彻底停摆：
-
select * from v$flash_recovery_area_usage;—— 重点关注ARCHIVELOG对应的两个百分比 - 别只调大
db_recovery_file_dest_size：先用 RMAN 清理旧归档，例如delete archivelog until time 'sysdate-3';，再crosscheck archivelog all; - 扩容要留余量：
alter system set db_recovery_file_dest_size = 15G scope=both;（根据实际归档速率定，别只加 1G）
归档链通了，必须强制切换验证
空间和权限问题解决后，别急着 open 数据库，先让 ARCn 活起来：
-
alter system archive log current;—— 成功返回说明归档链已通，这是关键验证点 - 失败则再查
v$managed_standby：确认ARCH（主库归档进程）和LNS（LGWR 网络服务）状态为CO
真正容易被忽略的是：修复后不验证 archive log current 就去启 MRP，结果 gap 依然存在；或者清理 FRA 时只删 archivelog，忘了 crosscheck，导致 RMAN 认为归档还在，ARCn 仍拒绝写入。
