ora-16014本质是归档链断裂而非日志损坏，95%以上情况只需恢复归档路径可用性；严禁执行clear unarchived logfile，否则导致主备序列号丢失、mrp卡gap甚至需重建备库。
ora-16014 不是日志损坏，而是归档链断了——95% 以上的情况只需恢复归档路径可用性，千万别直接 clear unarchived logfile。
检查归档目标是否全部失效
错误日志里明确写着 "no available destinations"，说明所有 LOG_ARCHIVE_DEST_n 都没处于 VALID 状态。这不是数据库坏了，是它“找不到地方存归档”。
- 运行
select dest_id, status, target, error from v$archive_dest where status != 'VALID';，看哪些目标报ERROR或INACTIVE - 对每个
target路径，用操作系统命令验证：目录是否存在、Oracle OS 用户是否有写权限、磁盘剩余空间是否 ≥ 当前最大归档文件的 2 倍（避免写到一半失败） - 若使用 ASM，查
v$asm_diskgroup确认对应 diskgroup 是MOUNTED状态，不是DISMOUNTED
确认闪回区（FRA）是否真实撑满
db_recovery_file_dest_size 设置太小只是表象，关键要看 v$flash_recovery_area_usage 里 PERCENT_SPACE_RECLAIMABLE 是否为 0 —— 如果是，说明 RMAN 没法自动清理旧归档或备份，光调大参数没用。
- 执行
select * from v$flash_recovery_area_usage;，重点关注ARCHIVELOG行的PERCENT_SPACE_USED和PERCENT_SPACE_RECLAIMABLE - 若
PERCENT_SPACE_RECLAIMABLE = 0，先用 RMAN 清理：delete archivelog until time 'sysdate-2';crosscheck archivelog all;delete expired archivelog all; - 再执行
alter system archive log current;测试能否成功归档；失败则说明问题不在 FRA，而在其他归档目标
排查 LOG_ARCHIVE_DEST_n 的 VALID_FOR 和 DB_UNIQUE_NAME 配置冲突
DG 环境下，主库和备库的 LOG_ARCHIVE_DEST_1 必须严格匹配角色与唯一名。常见坑是：从主库拷贝参数后忘了改 DB_UNIQUE_NAME，或者 VALID_FOR 写成 (ONLINE_LOGFILES, ALL_ROLES) 导致备库试图归档自己的 standby log。
- 在备库上运行
show parameter log_archive_dest_1，检查DB_UNIQUE_NAME值是否等于本库的db_unique_name（不是主库的！） - 确认
VALID_FOR是(ALL_LOGFILES, ALL_ROLES)或(STANDBY_LOGFILES, STANDBY_ROLE)，绝不能出现ONLINE_LOGFILES+STANDBY_ROLE这种非法组合 - 如果用了
standby_archive_dest，确保它和log_archive_dest_1指向同一位置，否则 Oracle 12c+ 可能因内部判断逻辑冲突而拒绝归档（参考 MOS ID 834771.1）
为什么 CLEAR UNARCHIVED LOGFILE 在 DG 中绝对禁止
这个命令会跳过归档校验，直接重建日志文件，导致该 sequence# 永久丢失。备库 MRP 进程收不到对应归档，立刻卡在 gap，后续只能重建备库——没有例外。
- 它不解决归档传输问题，只掩盖症状；真正的归档链断裂仍存在
- 一旦执行，主库日志序列号出现空洞，
v$archived_log里会缺失该 sequence，备库v$archive_gap显示 gap 起止，但无法自动补齐 - 修复必须回到归档路径、权限、空间、配置这四点，而不是动日志文件本身
最易被忽略的是：RAC 环境下要查 gv$archive_dest，单节点查 v$archive_dest，漏掉一个节点的状态就可能误判；另外 NFS 挂载选项（如 noac）导致的“看似可写实则挂起”，需用 touch 实测写入延迟。
