RAC中直接删归档会出问题,因各节点默认只管理本地归档路径,RMAN在单节点执行DELETE ARCHIVELOG ALL会静默遗漏其他节点归档,导致恢复时序列断层报ORA-00329/ORA-00310;且v$archived_log中APPLIED='YES'仅反映本节点状态,无法保证跨节点传输与应用进度,误删未同步至备库的归档可能中断Data Guard甚至需重建备库。

为什么RAC中直接删归档会出问题
RAC里各节点默认只管自己生成的归档,LOG_ARCHIVE_DEST_1若指向本地路径(比如/u01/arch),RMAN在节点1执行DELETE ARCHIVELOG ALL时根本看不到节点2的归档文件。这不是报错,而是静默遗漏——恢复时遇到序列号断层,直接报ORA-00329或ORA-00310。
更危险的是:归档路径不统一,v$archived_log里APPLIED = 'YES'只反映本节点状态,跨节点应用进度无法保证。误删未传输到所有备库的归档,可能让Data Guard同步中断,甚至需重建备库。
- 别信
STATUS = 'A',它只表示“归档完成”,不等于“已传输”或“已应用” - 查
v$archive_gap必须返回空结果,否则说明主库有归档没传到备库 -
SHOW PARAMETER log_archive_dest_1在每个节点都得执行,确认值是+FRA或/shared_nfs/arch这类共享路径
清理前必须确认的三件事
跳过这步就动手,大概率删掉还在用的日志。不是“建议”,是硬性前置条件。
- 在任一节点查:
SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;——结果集必须为空 - 查主库
v$archive_dest_status中对应DG目标的STATUS = 'VALID'且ERROR列为空 - 确认
RMAN配置的删除策略是SHIPPED TO ALL STANDBY,不是默认的APPLIED ON ALL STANDBY(后者在ADG场景下会误判)
执行SHOW ARCHIVELOG DELETION POLICY;,输出必须是SHIPPED TO ALL STANDBY。如果不是,立刻运行:CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
RMAN清理命令必须带CROSSCHECK和显式通道
不先CROSSCHECK ARCHIVELOG ALL,控制文件里残留的“幽灵记录”会让后续DELETE静默跳过大量物理文件,空间根本清不掉。
RAC中BACKUP ARCHIVELOG ALL或DELETE ARCHIVELOG默认只扫当前连接实例的路径。必须手动分配跨节点通道:
rman target /
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK CONNECT 'sys/password@rac1';
ALLOCATE CHANNEL c2 DEVICE TYPE DISK CONNECT 'sys/password@rac2';
CROSSCHECK ARCHIVELOG ALL;
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE - 3';
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
}-
CROSSCHECK必须在DELETE之前,且对所有节点生效(RMAN自动识别RAC上下文) -
UNTIL TIME比COMPLETED BEFORE更安全,避免节点间时间差导致漏删 - 别用
DELETE ARCHIVELOG ALL——它不检查应用/传输状态,纯按控制文件记录删
定时脚本里最容易踩的坑
网上流传的del_arch.sh脚本常漏掉关键点,跑一周后发现空间又满了。
- 脚本里
source ~/.bash_profile必须确保加载了正确的ORACLE_SID,RAC中多个实例时容易连错 -
delete noprompt archivelog all completed before 'sysdate-15'这种写法危险:completed before依赖各节点SCN推进速度,时间差2秒就可能漏归档 - 日志路径没统一?脚本在节点1跑完,节点2的归档还在原地膨胀
- 清理后
V$FLASH_RECOVERY_AREA_USAGE中PERCENT_SPACE_USED不降?等5–10分钟再查;长期不降要怀疑control_file_record_keep_time设太小
真正可靠的定时清理,核心就两条:所有节点log_archive_dest_1指向同一ASM磁盘组(如+FRA),且每次RMAN操作都显式分配多通道并强制CROSSCHECK。其他都是补救措施。


















