ora-16014 表明归档链断裂而非归档损坏：主库日志未传输导致备库卡在 wait_for_log；需检查归档目标可用性、fra 空间、实时应用配置及 data guard 参数一致性。
ORA-16014 不是归档损坏，而是归档链断裂的明确信号：主库有日志没传出去，备库就卡死在 WAIT_FOR_LOG。 直接 ALTER DATABASE CLEAR UNARCHIVED LOGFILE 会跳过序列校验，导致备库报 ORA-00314 或 gap，重建是唯一退路。
查归档目标是否真可用，别只看参数值
很多 DBA 看到 log_archive_dest_2 配置了路径就以为 OK，其实 OS 层权限、磁盘空间、目录是否存在都可能断链：
-
archive log list输出里Archive destination必须是ENABLED，且Latest log sequence在持续增长 -
show parameter log_archive_dest_2查路径后，手动用 Oracle OS 用户（如oracle）执行ls -ld /path/to/arch和df -h /path/to/arch，确认可写、剩余空间 ≥ 2× 当前最大单个归档大小 -
select * from v$archive_dest where dest_id = 2;看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 RECOVER MANAGED STANDBY DATABASE DISCONNECT NODELAY 不启用实时应用，它只启动介质恢复，MRP0 状态会是 WAIT_FOR_LOG 或 NOT ACTIVE：
- 真正生效的命令是：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 漏掉
USING CURRENT LOGFILE，就等于告诉 Oracle “等归档落盘后再开始”，自然无法实时 - 检查
v$managed_standby：MRP0 的PROCESS应为MRP0，STATUS应为APPLYING_LOG，且SEQUENCE#持续递增
最易被忽略的是：即使 v$archive_gap 返回空，也不代表已应用；必须交叉验证 v$dataguard_stats 中的 apply lag 和 transport lag，以及 standby_file_management 是否为 AUTO —— 若为 MANUAL 且主库新增了数据文件，MRP0 遇到 UNNAMED 文件会静默挂起，不报错也不推进。
