归档日志删除不生效主因是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 认为“部分归档不可见”，直接放弃整批清理。