为什么要定期清理归档日志
Oracle 数据库开启归档模式后，所有事务重做日志都会被保留为归档日志（Archived Log）。随着时间推移，归档日志会迅速挤占 FRA（Fast Recovery Area）或文件系统空间，导致数据库挂起。因此需要周期性、可回退地清理。
清理前必须做的两件事
检查日志同步与备份
- 通过 Data Guard、OGG、DSG 等同步监控平台，确认所有下游库均已应用完毕。
- 对即将删除的归档日志再做一次备份，防止误删后无法找回。
风险评估
- 禁止直接在操作系统层
rm -rf删除归档文件，极易造成 RMAN 元数据与物理文件不一致。- 统一使用 RMAN 删除命令，配合
CROSSCHECK/DELETE ... BACKED UP n TIMES，确保只有已备份、已应用的日志才会被清理。
实施步骤
检查归档日志当前占用
-- 查看归档日志列表
SQL> select name, first_time, backup_count
from v$archived_log
order by first_time;
-- 检查 FRA 空间
SQL> select group_number, name, total_mb, free_mb
from v$asm_diskgroup
where name = 'FRA';示例输出：
NAME FIRST_TIME BACKUP_COUNT
---------------------------------------------------------------- ------------------- ------------
+FRA/orclasm/archivelog/2016_04_14/thread_1_seq_7.270.909138063 2016-04-14 10:04:48 0
+FRA/orclasm/archivelog/2016_04_14/thread_1_seq_8.271.909138063 2016-04-14 10:16:48 0
+FRA/orclasm/archivelog/2016_04_14/thread_1_seq_9.272.909138081 2016-04-14 10:18:10 0磁盘组 FRA 剩余 1395 MB，已逼近告警线（默认 80%）。
登录 RMAN
$ rman target sys/***@PROD1521 catalog cataadmin/catapswd@PROD21521校验归档日志有效性
RMAN> crosscheck archivelog all;
RMAN> list expired archivelog all;
crosscheck会把物理丢失但记录在控制文件中的归档标记为EXPIRED。- 确认 EXPIRED 列表中不再有需要保留的日志。
执行删除（按序列号）
RMAN> delete noprompt archivelog until sequence 12;
- 关键字
noprompt在脚本中可自动确认；交互场景去掉即可二次确认。- 删除完成后，日志显示 Deleted 9 objects。
立即验证
- 手工切换日志，确保归档进程正常：RMAN> sql “alter system archive log current”;
- 再次查看 FRA 空间：GROUP_NUMBER NAME TOTAL_MB FREE_MB
———— —- ———- ——–
2 FRA 10240 2131已释放 736 MB。
回退方案（删错了怎么办？）
场景 回退步骤 误删尚未同步的归档 1. 停止日志应用进程；2. 使用清理前的备份片还原归档： RMAN> restore archivelog sequence between n and m;误删尚未备份的归档 1. 立即拉起备份；2. 若备份也无，则考虑闪回数据库或基于时间点的恢复（前提：有全备 + 剩余归档）。
- 查看数据库 alert 日志、RMAN 日志，确认无 ORA-00257 等报错。
- 将清理脚本加入 crontab，按保留策略（如“归档保留 7 天且已备份 2 次”）定期执行：delete archivelog all completed before ‘sysdate-7’ backed up 2 times to device type sbt;
- 监控 FRA 使用率，推荐阈值：>85% 告警，>95% 立即清理。
- 不碰 OS 层文件，所有操作交由 RMAN，保证元数据一致。
- 先校验，再删除，后验证，三步缺一不可。
- 保留二次备份窗口，任何清理都可回退。