rac中单节点归档满会导致所有实例卡住，因该节点触发“stuck archiver”无法切换日志，阻塞dml并拖慢全局scn推进，影响其他节点事务协调；需通过v$flash_recovery_area_usage统一判断归档使用率≥95%、log_archive_dest_1是否指向本地路径、gv$instance定位故障inst_id，并用crosscheck archivelog all确保rman清理元数据与物理文件一致。
为什么RAC中一个节点归档满会让所有实例卡住
因为归档进程（ARCn）是实例级的，但归档日志写入目标（log_archive_dest_1）若配置为本地路径（如/u01/arch），会导致各节点各自写入、互不感知；而一旦任一节点的本地归档目录满，其ARCn进程就会挂起，进而触发该实例的“Stuck Archiver”状态——此时该实例无法完成日志切换，online redo log写满后阻塞所有DML，业务连接排队直至超时。更关键的是：RAC共享存储架构下，所有实例共用同一套控制文件和数据文件，某个实例因归档卡死而无法推进SCN，会拖慢全局事务协调，其他节点虽未满，也会因等待或LMS/LMD进程异常而响应迟缓甚至假死。
如何快速判断是不是单节点归档满引发的连锁反应
执行以下检查，不要逐节点登录：
-
SELECT * FROM v$flash_recovery_area_usage;—— 这个视图在RAC中对所有实例统一有效，只要ARCHIVELOG行的percent_space_used≥ 95%，就说明闪回区已满，无需查每个节点 -
SHOW PARAMETER log_archive_dest_1;—— 如果返回值是类似LOCATION=/u01/arch这种本地路径，而非LOCATION=+FRA等ASM共享路径，就是典型风险配置 -
SELECT inst_id, archiver, log_switch_wait FROM gv$instance;—— 若某行archiver为STOPPED或log_switch_wait为ARCHIVE LOG，对应inst_id即为故障节点
RMAN清理时为什么必须用CROSSCHECK ALL而不是直接DELETE
RAC环境下归档日志可能分散写入不同节点的本地目录，而控制文件只记录被成功归档过的日志元数据；如果某节点曾宕机或归档失败，控制文件里就缺失这部分记录。不执行CROSSCHECK ARCHIVELOG ALL，RMAN只会清理它“认为存在”的归档，大量物理文件残留，DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'也无效——因为那些旧文件根本不在元数据里，RMAN看不见。
真正释放空间的关键动作常被忽略
RMAN只能删掉控制文件里有记录的归档；但control_file_record_keep_time默认仅7天，超过这个窗口的归档元数据已被覆盖。这意味着：你执行完全部RMAN命令后，df -h仍显示空间没释放，是因为目录里堆着大量“RMAN看不见”的*.dbf文件。必须手工清理：
- 确认业务恢复窗口（例如备份策略只要14天），且这些文件不在任何RMAN备份集中
- 进入真实归档路径（不是
db_recovery_file_dest，而是log_archive_dest_1指向的位置） - 用
find . -name "*.dbf" -mtime +15 -delete删除15天前的物理文件
这步不做，下次报警只是时间问题。
