ORA-16014与ORA-00312在DG环境中表明归档链断裂，主库日志未成功归档传输；直接执行CLEAR UNARCHIVED LOGFILE会丢失日志序列号，破坏主备一致性，导致备库MRP进程卡gap甚至需重建，属高危操作。
ora-16014 + ora-00312 在 dg 环境中不能直接用 alter database clear unarchived logfile 硬清日志组——这会破坏主备一致性，甚至导致备库无法应用归档。
为什么 DG 环境下 CLEAR UNARCHIVED LOGFILE 是高危操作
在 Data Guard 配置中，主库的每个在线重做日志（ONLINE LOG）必须成功归档并传输到备库后，才能被覆盖。一旦出现 ORA-16014，说明归档链断裂：要么归档目标不可写、空间满，要么归档进程（ARCn）异常挂起，但日志本身未损坏。此时若执行 clear unarchived logfile group X，Oracle 会跳过归档校验、直接重建日志文件，导致该日志序列号（如 sequence# 187）永久丢失。备库因收不到对应归档，MRP 进程将报 ORA-00314 或卡在 gap，后续只能重建备库或手动补日志（极难还原）。
优先检查归档路径与闪回区空间是否真实可用
绝大多数 ORA-16014 在 DG 中实际是空间或权限问题，而非日志损坏：
-
show parameter db_recovery_file_dest和show parameter log_archive_dest_1必须同时检查——DG 要求至少一个有效归档目标（log_archive_dest_1或log_archive_dest_2）处于VALID状态 -
select * from v$flash_recovery_area_usage;查看ARCHIVELOG是否已占满（>95%），PERCENT_SPACE_RECLAIMABLE为 0 表示 RMAN 没有可清理的过期备份/归档 - 确认
log_archive_dest_1对应的目录存在、Oracle OS 用户有写权限、磁盘剩余空间 ≥ 2× 当前最大归档大小（避免归档中途失败） - 运行
archive log list，观察输出中Archive destination是否显示ENABLED且Latest log sequence在增长
修复步骤：先恢复归档能力，再触发归档切换
不要一上来就动日志文件。目标是让 ARCn 进程能继续工作：
- 如果闪回区满：
alter system set db_recovery_file_dest_size = 10G scope=both;（根据磁盘实际扩容，非临时凑数） - 如果归档目录满或不可写：用 RMAN 清理旧归档，例如
delete archivelog until time 'sysdate-3';，再crosscheck archivelog all; - 强制归档当前日志：
alter system archive log current;—— 成功则说明归档链已通，数据库可open - 若仍失败，检查
select process, status, thread#, sequence# from v$managed_standby;，确认ARCH和LNS进程状态为CONNECTED，MRP在备库是否活跃
仅当归档目标全部失效且业务不可停时才考虑日志组重建
这是最后手段，且必须满足两个前提：
- 确认 DG 已降级为非保护模式（如
PROTECTION MODE = MAXIMUM PERFORMANCE），且备库已明确放弃同步（即接受数据丢失） - 确认出问题的日志组不是
CURRENT（查v$log.status），否则CLEAR会导致实例崩溃 - 操作前务必备份控制文件：
alter database backup controlfile to trace; - 执行：
alter database clear unarchived logfile group 1;，随后立即alter system switch logfile;触发新日志归档
注意：clear unarchived 后，该日志序列号在主库和备库之间彻底断开，DG 需要重新搭建物理备库或切换为逻辑备库补数据——这不是“修复”，而是“绕过”。
