ORA-16014 表明归档链断裂而非日志损坏，需检查归档目标可用性、FRA空间及权限，严禁CLEAR UNARCHIVED LOGFILE，修复后验证ARCn与MRP状态。
ORA-16014 不是日志损坏，而是归档链断裂的明确信号——主库有日志没传出去，备库收不到，MRP 就卡住。不能直接 CLEAR UNARCHIVED LOGFILE，否则备库立刻报 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）
DG 环境下绝对禁止硬清日志组
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP X 在 DG 中等于主动撕毁主备契约：
- 该命令绕过归档检查，直接重建日志文件，对应序列号（如
sequence# 187）永久丢失 - 备库 MRP 进程找不到这个归档，卡在 gap，
select process, status, thread#, sequence# from v$managed_standby;会显示 MRP 为WAIT_FOR_LOG - 修复代价极高：要么手动补全缺失归档（几乎不可能），要么重建备库
归档链通了，再强制切换验证
空间和权限问题解决后，别急着 open 数据库，先让 ARCn 活起来：
-
alter system archive log current;—— 触发一次归档，观察archive log list的Latest log sequence是否递增 - 再查
v$archive_dest的ERROR列是否清空、STATUS是否变VALID - 最后在备库确认：
select process, status, thread#, sequence# from v$managed_standby;中 MRP 是否为APPLYING_LOG
最易被忽略的是：ERROR 列为空 ≠ 归档链畅通；archive log list 显示 ENABLED ≠ 目录真实可写；FRA 空间回收延迟可能导致清理后仍卡住——必须等 PERCENT_SPACE_RECLAIMABLE > 0 再验证。
