归档空间爆满时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 仓库，四层状态要对齐，漏一层就反复发作。
