如何处理RAC环境的归档空间爆满_所有节点归档日志的集中清理策略-Oracle-PHP中文网

归档空间爆满时ARCHIVE LOG LIST显示NO但磁盘已满，需先确认共享归档路径实际使用率，再逐节点清理并同步归档状态。

归档空间爆满时，`ARCHIVE LOG LIST` 显示 `NO` 但实际磁盘已满怎么办

rac 环境下归档路径通常指向共享存储（如 asm 或 nfs），但每个节点的 archive log list 只显示本节点归档状态，容易误判。常见现象是：某节点执行 archive log list 返回 no（即未启用归档），但共享归档目录早已占满，导致所有实例 hang 在 log switch 上。

先确认真实归档目标：SHOW PARAMETER log_archive_dest_1，重点看 LOCATION 值是否为共享路径（如 +FRA 或 /u01/arch）
不要只查一个节点，用 crsctl stat res -t | grep ora.asm 确认 ASM 实例是否全部 online，再进每个节点查 asmcmd lsdg（若用 ASM）或 df -h（若用文件系统）
归档写入失败不会立刻报错到 alert.log，而是表现为 ORA-00257: archiver error. Connect internal only, until freed. —— 这个错误出现时，归档空间大概率已不可写

用 `RMAN` 清理归档日志前，必须绕开 RAC 节点间归档同步锁

RAC 中多个实例可能同时尝试删除同一份归档（尤其在使用 DELETE ARCHIVELOG ALL 时），触发 ORA-19606: Cannot copy or restore to snapshot control file 或静默跳过部分文件。根本原因是 RMAN 默认以单实例模式连接，不感知集群锁机制。

清理前必须用 CONNECT TARGET / 连接本地实例，且确保 ORACLE_SID 指向当前节点（不能靠 tnsnames.ora 别名连）
强制指定归档路径范围，避免跨节点误删：DELETE ARCHIVELOG FROM TIME 'SYSDATE-7' COMPLETED BEFORE 'SYSDATE-1'; —— 不要用 ALL
加 NOPROMPT 和 FORCE 参数防止交互中断：DELETE NOPROMPT FORCE ARCHIVELOG UNTIL TIME 'SYSDATE-3';
如果归档在 ASM 中，LIST ARCHIVELOG ALL 可能卡住，改用 LIST ARCHIVELOG FROM TIME 'SYSDATE-5'; 缩小扫描范围

`log_archive_dest_1` 指向本地文件系统时，各节点归档互不干扰但空间难统一管理

有些 RAC 部署把归档路径设为本地路径（如 /u01/arch/node1），看似隔离，实则埋雷：DBA 习惯性只清一个节点，其他节点持续写入直至磁盘满，引发实例崩溃；更麻烦的是，LOG_ARCHIVE_DEST_STATE_1=DEFER 后未及时恢复，归档会悄悄停摆。

检查所有节点的 log_archive_dest_1 是否一致：SELECT INST_ID, NAME, VALUE FROM GV$PARAMETER WHERE NAME = 'log_archive_dest_1';
若确为本地路径，清理必须逐节点执行，并确认 log_archive_dest_state_1 全部为 ENABLE（用 ALTER SYSTEM SET log_archive_dest_state_1=ENABLE SCOPE=BOTH SID='*'; 批量生效）
切勿直接 rm -f 归档文件 —— RAC 下控制文件可能未同步删除记录，下次启动报 ORA-19527（physical standby 场景更敏感）
临时扩容可快速挂载新盘并切换路径：ALTER SYSTEM SET log_archive_dest_1='LOCATION=/newarch' SCOPE=BOTH SID='node1';，但需立即备份控制文件

归档清理后，`ARCHIVE LOG LIST` 仍显示 `PENDING` 或 `FAILED` 怎么办

这不是清理没成功，而是归档进程（ARCn）缓存了失败任务。RAC 中某个节点 ARCn 持续重试已不存在的归档目标，会在 alert.log 里刷屏 ARCn: Failed to archive thread 1 sequence 12345，CPU 占用飙升。

查具体失败归档：SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME, DEST_ID FROM V$ARCHIVED_LOG WHERE DELETED='NO' AND STANDBY_DEST='NO' ORDER BY FIRST_TIME DESC;
手动清除归档记录（仅当确认物理文件已删）：ALTER DATABASE REGISTER LOGFILE '/path/to/missing/arch_12345.arc'; 再 DELETE ARCHIVELOG ...，否则控制文件残留元数据
重启 ARCn 进程无效，必须重启对应实例的归档进程：ALTER SYSTEM ARCHIVE LOG CURRENT; 触发一次正常归档，ARCn 自动恢复
长期方案：设置 log_archive_max_processes=4（默认 4，但某些版本 RAC 下需显式调大），避免单个 ARCn 卡死阻塞全局

归档空间问题最麻烦的不是清理动作本身，而是 RAC 环境下“哪个节点写了什么、哪个节点删了什么、哪个节点还记着什么”这三者不同步 —— 控制文件、ASM 元数据、操作系统文件系统、RMAN 仓库，四层状态要对齐，漏一层就反复发作。