归档日志删除不生效主因是RMAN未连接到RAC共享恢复目录或未正确配置共享FRA；须用SCAN服务连接、确认DB_RECOVERY_FILE_DEST指向同一ASM组、使用TO APPLIED ON ALL STANDBY策略，并避免CROSSCHECK误标EXPIRED。
归档日志删除不生效？检查 RMAN 连接的是不是真正的 RAC 共享恢复目录
很多情况下删不掉归档，不是策略写错了，而是 rman 没连对地方。rac 环境下，如果只用 connect target / 连到某个节点，rman 默认只看到该节点本地的归档路径（比如 +fra/db_name/archivelog/... 中某节点私有目录），而真正共享的归档位置（如 +fra 下按时间戳组织的统一目录）可能根本没被扫描。
- 必须显式连接到共享的恢复目录（如果有）或使用
CONNECT TARGET sys/password@service_name，其中service_name指向 SCAN VIP 且配置了LOAD_BALANCE=ON的服务，确保会话能跨节点发现全部归档 - 验证方式：在
RMAN中运行LIST ARCHIVELOG ALL;，观察输出是否包含所有节点生成的归档序列号，而非仅当前实例的 - 若无恢复目录，且使用 FRA 存储归档，确认所有节点的
DB_RECOVERY_FILE_DEST指向同一 ASM 磁盘组（如+FRA），否则各节点写入不同路径，RMAN删除时天然“看不见”别的节点文件
CONFIGURE ARCHIVELOG DELETION POLICY 在 RAC 下必须用 TO APPLIED ON ALL STANDBY 才安全
RAC 本身不直接参与归档删除决策，但它的高可用架构会让主库归档被多个备库拉取。如果策略设成 TO SHIPPED TO ALL STANDBY，只要任一备库网络抖动、延迟或未注册，归档就卡住不删；而 TO APPLIED ON ALL STANDBY 要求真正应用完成，虽略保守，但在 RAC+Data Guard 组合中才是可落地的底线。
-
TO APPLIED ON ALL STANDBY是唯一能避免“归档堆积压垮 FRA”的策略，尤其当备库启用 Real-Time Apply 或有延迟应用窗口时 - 不要用
BACKED UP n TIMES TO DEVICE TYPE配合磁带备份——RAC 各节点独立发起备份会导致计数不一致，RMAN无法准确判断是否真备份了 n 次 - 执行前先查备库状态：
SELECT DEST_NAME, STATUS, PROTECTION_MODE, SYNCHRONIZATION_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE STATUS = 'VALID';，确保所有VALID备库都在线且同步正常
手动删除前务必绕过 crosscheck 直接用 DELETE ARCHIVELOG 加条件
RAC 环境下 CROSSCHECK ARCHIVELOG ALL 极其危险：它会逐个节点扫描控制文件记录的归档，而各节点控制文件未必实时同步，容易把已删除或跨节点移动过的归档标为 EXPIRED，后续 DELETE EXPIRED 可能误删实际还存在的文件。
- 改用精准删除命令：
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-3' BACKED UP 1 TIMES TO DISK;—— 明确时间范围 + 确认备份次数，不依赖 crosscheck 状态 - 加
DBID限定更稳妥（尤其共用 FRA 的多库环境）：DELETE ARCHIVELOG FROM SEQUENCE 1000 UNTIL SEQUENCE 2000 DBID 123456789; - 删除前先
LIST ARCHIVELOG FROM TIME 'SYSDATE-3';预览，确认列表里确实是目标节点+目标时间范围内的归档
节点间 FRA 空间感知不同步？靠 V$RECOVERY_AREA_USAGE 查不到全貌
V$RECOVERY_AREA_USAGE 是单实例视图，每个节点只汇报自己看到的 FRA 使用率。即使总空间还有 30%，某个节点因本地写入密集+未及时清理，可能已经触发 ORA-19809 报错停归档——这时看全局视图毫无意义。
- 必须在每个节点分别查：
SELECT * FROM V$RECOVERY_AREA_USAGE;，重点关注PERCENT_SPACE_USED和NUMBER_OF_FILES是否异常高于其他节点 - 真正有效的监控是定期跑脚本：
SELECT INST_ID, ROUND((SPACE_LIMIT - SPACE_USED)/1024/1024/1024,1) GB_FREE FROM GV$RECOVERY_FILE_DEST;，用GV$视图聚合所有节点数据 - 自动清理失效后，临时救急别只清归档：可配合
DELETE OBSOLETE清理过期备份，或调整DB_RECOVERY_FILE_DEST_SIZE（需重启实例才生效，慎用）
最常被忽略的一点：RAC 归档删除策略生效的前提，是所有节点的 LOG_ARCHIVE_DEST_n 都正确指向共享位置，且没有节点偷偷配了本地文件系统路径（比如 /u01/arch）。这种混搭会让 RMAN 认为“部分归档不可见”，直接放弃整批清理。
