ora-16014 表明 data guard 归档链断裂，非日志损坏；需检查归档目标可用性、闪回区空间及权限，严禁 clear unarchived logfile，修复后执行 alter system archive log current 验证归档链畅通。
ora-16014 在 data guard 环境中不是日志损坏问题，而是归档链断裂的明确信号——主库有日志没传出去，备库收不到，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;—— 成功返回说明归档链已通，这是关键验证点 - 失败则再查
v$managed_standby：确认ARCH（主库归档进程）和LNS（LGWR 网络服务）状态为CONNECTED，不是FAILED或UNKNOWN - 最后执行
alter database open;—— 此时才真正安全
真正难的不是操作步骤，而是判断归档中断到底是空间不足、权限缺失，还是网络/备库端异常；v$archive_dest 和 v$managed_standby 的 ERROR 列，比任何日志都直白。
