ORA-16014 根因是归档链中断而非日志损坏，主库归档未传输导致备库MRP卡住；需检查归档目标可用性、FRA空间、权限及禁止误用CLEAR UNARCHIVED LOGFILE。
ORA-16014 不是日志损坏，而是归档链断了——主库有日志没传出去，备库收不到，MRP 就卡住。
查归档目标是否真可用，别只看参数值
很多 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
该命令在 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;—— 成功返回说明归档链已通，这是关键验证点 - 失败则再查
v$managed_standby和v$archive_dest，重点看 ERROR 列和 STATUS 字段
最常被忽略的是 FRA 里 PERCENT_SPACE_RECLAIMABLE 为 0 却没触发自动清理——这说明归档日志被 backup 或应用进程（如 MRP）仍持有引用，得人工介入确认 backup 状态或暂停 MRP 后清理。
