备库归档清理必须先确认已应用且无gap，再用rman清理可见归档，最后手动删除rman不可见的老文件；脚本化操作需加锁、校验状态并记录日志。
备库归档目录爆满，不能直接 rm -f，也不能只靠 DELETE ARCHIVELOG ALL —— RMAN 看不见超过 control_file_record_keep_time（默认 7 天）的物理文件，删了也白删；而手删未应用归档会触发 GAP，同步断裂。
确认归档已应用且无 GAP，否则停手
这是所有操作的前提。误删未应用归档，备库立刻脱机，重建代价远高于空间问题本身。
- 查最新归档是否已应用：
SELECT MAX(SEQUENCE#) FROM v$archived_log WHERE applied = 'YES' AND DEST_ID = 2（DEST_ID需先从v$archive_dest确认，常见为 1 或 2） - 查 GAP：
SELECT * FROM v$archive_gap，返回空集才安全 - 查 MRP 进程状态：
SELECT process, status, sequence# FROM v$managed_standby WHERE process = 'MRP0'，必须是APPLYING_LOG且sequence#持续增长 - 若发现
applied = 'NO'或 GAP 非空，先解决传输或应用卡顿，比如重启 MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT
RMAN 清理“看得见”的归档：先 crosscheck，再删 expired 和已应用部分
这步不跳过，否则后续命令可能静默跳过、报 RMAN-08137，或留下元数据脏记录影响后续日志应用。
- 进入 RMAN：
rman target / - 强制同步磁盘与控制文件：
CROSSCHECK ARCHIVELOG ALL - 清理失效记录：
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL - 删已应用且超保留窗口的归档（推荐用
COMPLETED BEFORE）：DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' - 注意：
UNTIL TIME查的是FIRST_TIME，在频繁切换日志时可能误删；COMPLETED BEFORE更稳
手动清理 RMAN “看不见”的物理残留文件
这才是释放大量空间的关键。控制文件元数据只保留约 7 天，老归档文件 RMAN 根本不识别，但它们真实占着磁盘。
- 前提：确认这些文件超出业务恢复窗口（如备份策略只要保留 14 天），且不在任何 RMAN 备份集中（
LIST BACKUP OF ARCHIVELOG验证） - 进归档目录（如
/oracle/app/archivelog），执行：find . -name "*.dbf" -mtime +15 -type f -print0 | xargs -0 rm -f -
+15是缓冲值（比保留窗口多 8 天），避免刚被 RMAN 删掉就又被find扫到 - 务必加
-print0和xargs -0，防止文件名含空格或特殊字符出错 - 不要用
rm -rf *或模糊时间范围，否则极易误删
脚本化清理必须带锁、环境变量和状态校验
自动清理不是配个 crontab 就完事。生产环境出过太多因并发执行、环境缺失或状态未检导致的同步中断。
- 脚本开头必须检查：
v$archive_gap、v$managed_standby中 MRP 状态、v$archived_log最大已应用SEQUENCE# - 加文件锁（如
flock -n /tmp/dg_arch_clean.lock -c "..."），防多个实例同时运行 - 显式设置环境：
export ORACLE_SID=xxx; export ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 - 所有操作记日志：
exec >> /home/oracle/scripts/logs/dg_clean_$(date +\%Y\%m\%d).log 2>&1 - 清理后等 5–10 分钟再查
V$FLASH_RECOVERY_AREA_USAGE，PERCENT_SPACE_USED不降，大概率是控制文件统计延迟，不是没删干净
最易被忽略的点：RMAN 的 configure archivelog deletion policy to applied on standby 在备库上完全无效——它只在主库执行 DELETE INPUT 时触发校验，备库自己不发起删除动作。别配，配了也没用，还可能干扰升级。
