必须先确认备库归档已完全应用且无传输gap，再执行crosscheck标记失效记录、按时间删除已应用归档；否则会导致v$archived_log状态混乱、rman-08137报错或日志应用中断。
在 Oracle 19c DG 环境中，备库上堆积的归档日志不能直接用 rm 删除，否则 v$archived_log 中状态混乱、RMAN 报 RMAN-08137、甚至中断日志应用。必须先确认已应用且无 GAP，再分两步清理：先 crosscheck 标记失效记录，再按时间删已应用归档。
确认备库归档已完全应用且无传输 GAP
这是清理前不可跳过的一步。未确认就删，可能把还没应用的归档干掉，导致同步中断或需重建备库。
- 查已应用归档：
SELECT COUNT(*) FROM v$archived_log WHERE APPLIED = 'YES' AND FIRST_TIME —— 只有 <code>APPLIED = 'YES'的才真正安全，STATUS = 'A'仅作辅助参考 - 查传输 GAP：
SELECT * FROM v$archive_gap;—— 返回空结果才算无 GAP；若有数据，得先手工复制缺失归档并注册 - 查主库传输状态：
SELECT STATUS, ERROR FROM v$archive_dest_status WHERE DEST_ID = 2;—— 确保STATUS = 'VALID'且ERROR为空
用 RMAN 清理控制文件中的“僵尸”归档记录
如果之前手动 rm 过归档文件，或备份策略变更过，控制文件里会残留指向不存在文件的记录。不先清理这些，后续 delete archivelog until time 可能静默跳过、空间不释放。
- 进 RMAN 后立即执行：
CROSSCHECK ARCHIVELOG ALL;—— 将磁盘上找不到的归档标记为EXPIRED - 紧接着执行：
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;—— 清掉这些“幽灵记录”，否则v$archived_log里仍显示存在但实际已丢 - 这一步做完后，再查
LIST EXPIRED ARCHIVELOG ALL;应返回空
安全删除已应用的本地归档（含 FRA 和 ASM）
备库上归档通常写入 DB_RECOVERY_FILE_DEST（FRA）或显式配置的 LOG_ARCHIVE_DEST_1（如 ASM diskgroup）。清理时必须指定目标，避免误删远程归档。
- 删 FRA 中 3 天前已应用归档：
DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE - 3';—— 注意单引号不能漏，SYSDATE-72这类写法易出错，不推荐 - 若归档同时写入多个位置（比如
DEST_ID = 1是本地 FRA，DEST_ID = 2是远程），加FROM DEST_ID 1显式限定：DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE - 3' FROM DEST_ID 1; - 别用
DELETE ARCHIVELOG ALL;或DELETE INPUT;—— 前者危险，后者在备库无 backup 场景下不生效
检查空间是否真实释放
删完不等于磁盘空间立刻回来。常见卡点是控制文件统计延迟，V$RECOVERY_FILE_DEST.USED_SPACE 没刷新，导致误判清理失败。
- 查实时使用率：
SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE;—— 关注ARCHIVELOG行的PERCENT_SPACE_USED - 若仍高，等 5–10 分钟再查；长期不降，可能是
control_file_record_keep_time设置过大（默认 7 天），导致旧归档记录滞留 - 别依赖
df -h立即验证 —— FRA 下的文件删了，但 ASM diskgroup 的空间释放可能有几秒延迟
最易被忽略的是：DG 备库上 LOG_ARCHIVE_DEST_2 对应的远程归档（即主库发来的那份）永远不能在备库上用 RMAN 删，那是主库的归档，清理责任在主库侧。备库只管自己生成的本地归档（DEST_ID = 1）和已应用后的副本。混淆 DEST_ID 是导致误删的高频原因。
