ORA-16057报错时应重置归档传输通道而非删文件：主库先DEFER再ENABLE LOG_ARCHIVE_DEST_STATE_2，触发DG自动跳过丢失归档；备库清理归档需MOUNT状态下用RMAN SET ARCHIVELOG DELETION POLICY TO NONE后删除。
ORA-16057: DGID not found，归档传输卡住时怎么强制清空
当主库归档日志无法传到备库，arch进程挂起、v$archive_dest_status里显示 error 且状态长期为 deferred 或 inactive，最直接的干预不是删文件，而是重置归档传输通道的状态。oracle 不允许手动删除正在被 dg 管理的归档（尤其启用了 log_archive_dest_n 的 valid_for 和 db_unique_name 配置时），强行删 log_archive_dest_2 对应路径下的归档会触发 ora-16057 或 ora-16705。
正确做法是让主库“忘记”当前卡住的归档序列号，重新协商起点：
- 在主库执行：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;（先停传输） - 确认备库已应用完所有能应用的日志：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES'; - 在主库执行：
ALTER SYSTEM ARCHIVE LOG CURRENT;（确保最新日志已归档） - 再执行：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
这会触发主库向备库发起新的 LGWR 或 ARCH 连接，并基于备库当前 STANDBY_BECAME_PRIMARY_SCN 或 APPLIED_SCN 自动跳过已丢失/不可达的归档段——本质是重置同步窗口，不是清文件。
备库上清除残留归档但不破坏DG配置的方法
如果备库磁盘满，或归档目录里积压了大量 APPLIED=NO 且确认永远不会再用的日志（比如主库已切换为快照备库、或做了闪回数据库），可以清理，但必须绕过 Data Guard 的元数据校验。
直接 rm 归档文件会导致后续 RECOVER MANAGED STANDBY DATABASE 报 ORA-00308 / ORA-19505；而 DELETE ARCHIVELOG 在物理备库上默认被禁用（RMAN 提示 not allowed on physical standby）。
- 先在备库以
MOUNT状态启动：SHUTDOWN IMMEDIATE; STARTUP MOUNT; - 用 RMAN 进入并关闭检查：
RMAN TARGET /→SET ARCHIVELOG DELETION POLICY TO NONE; - 再删指定范围：
DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE 12345; - 删完立刻重启备库到
MANAGED RECOVERY状态：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
关键点：SET ARCHIVELOG DELETION POLICY TO NONE 是绕过 DG 保护策略的必要步骤，否则 RMAN 会拒绝执行——它不是“关闭归档管理”，只是临时忽略 Data Guard 的保留约束。
为什么 ALTER DATABASE CLEAR LOGFILE 不适用于 Data Guard 同步场景
有人看到主库 ALTER DATABASE CLEAR LOGFILE GROUP 1 能清联机日志，就想对归档也这么干。不行。CLEAR LOGFILE 只作用于 ONLINE REDO LOG，且要求该组处于 INACTIVE 状态；而归档日志（ARCHIVED LOG）是只读历史文件，Oracle 没有提供任何 DDL 命令去“清除”它——所谓“清除归档”，实际是删除文件 + 同步控制文件/RMAN仓库记录。
-
CLEAR LOGFILE会重置日志头、生成新序列号，但归档日志的 SCN 和时间戳是固化在文件头里的，删了就真丢了 - 在 DG 环境中，主库删了某个归档，备库仍会在
V$ARCHIVED_LOG中保留该记录，下次拉取时发现文件不存在，直接报 ORA-19505 并中断传输 - 真正该操作的是
ALTER SYSTEM SWITCH LOGFILE+ 后续归档路径轮转，而不是对已有归档做“clear”
验证是否真清除了传输阻塞：看这三个视图就够了
别只盯着 ARCH 进程有没有起来，重点看三处元数据是否自洽：
-
V$ARCHIVE_DEST_STATUS：查STATUS是否为VALID，ERROR列是否为空，TRANSMIT_MODE是否匹配预期（SYNC/ASYNC） -
V$ARCHIVED_LOG（主库）：查DEST_ID = 2的最新SEQUENCE#是否持续增长，DELETED是否为NO -
V$MANAGED_STANDBY（备库）：查PROCESS为LNS（主库端）和MRP0（备库端）的STATUS是否为APPLYING_LOG，SEQ#是否与主库最新归档序列接近
如果 V$ARCHIVE_DEST_STATUS.ERROR 显示 ORA-16191: Primary log shipping client not logged on to standby，说明主备间认证失败，不是归档堆积问题——这时候清日志毫无意义，得先检查 LOG_ARCHIVE_CONFIG 和密码文件同步。
