能连上数据库，但仅限sqlplus / as sysdba；普通用户连接失败，说明实例未崩溃，问题多为归档空间满而非存储故障。
ORA-00257报错时还能连上数据库吗
能，但仅限 sqlplus / as sysdba；普通用户连接会失败，应用直接报错。这是关键突破口——只要还能用 sysdba 登录，就说明实例没彻底崩溃，问题大概率出在归档空间，不是底层存储故障。
如果连 sysdba 都登录失败，先别急着删归档，得查 crsctl stat res -t 和 asmcmd lsdg，确认 ASM 磁盘组是否 online、是否有 free space。RAC 里磁盘组异常比归档满更致命，且症状相似。
RMAN清理前必须做的三件事
直接跑 DELETE ARCHIVELOG ALL 很可能删不干净，甚至触发 ORA-19606 错误。RAC 环境下归档日志元数据和物理文件容易脱节，必须先同步状态：
-
CROSSCHECK ARCHIVELOG ALL：强制扫描所有节点归档路径（哪怕路径是本地的），把控制文件里“标记存在”但磁盘上已丢失的归档标为EXPIRED - 检查
v$flash_recovery_area_usage中ARCHIVELOG行的percent_space_used，≥95% 就是明确信号 - 确认所有节点的
log_archive_dest_1是否指向同一共享路径（如+FRA或 NFS）；若指向本地路径（如/u01/arch/node1），必须逐节点清理，且要核对log_archive_dest_state_1全部为ENABLE
安全删除归档的 RMAN 命令组合
别用 DELETE ARCHIVELOG ALL，它在 RAC 下易跨节点误删或锁冲突。推荐分步执行：
CROSSCHECK ARCHIVELOG ALLDELETE NOPROMPT EXPIRED ARCHIVELOG ALLDELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE-7'DELETE NOPROMPT OBSOLETE
注意：UNTIL TIME 比 COMPLETED BEFORE 更可靠，避免因时间精度导致漏删；NOPROMPT 防止交互中断；OBSOLETE 清理的是备份片，不是归档日志，但它依赖 RETENTION POLICY，别设成 RECOVERY WINDOW OF 0 DAYS。
如果归档在 ASM 里且 LIST ARCHIVELOG ALL 卡住，改用 LIST ARCHIVELOG FROM TIME 'SYSDATE-5' 缩小范围。
删完还剩空间？可能是控制文件没记录的老归档
RMAN 删不掉那些“早被踢出控制文件”的老归档——control_file_record_keep_time 默认约 30 天，超期后元数据就被覆盖。这些文件物理存在、RMAN 看不见，只能手工删。
先用操作系统命令定位：ls -lt /path/to/archivelog | head -20 找出最旧的几个 .arc 文件，确认它们不在 v$archived_log 里（查 first_time 范围），再 rm。若归档在 ASM，用 CATALOG START WITH '+FRA' 把散落的归档重新注册进控制文件，再走 RMAN 删除流程。
真正麻烦的不是删不掉，而是删完又满——根源几乎都在 log_archive_dest_1 指向本地路径，或 db_recovery_file_dest 所在 ASM 磁盘组本身已满。扩容 db_recovery_file_dest_size 之前，先确保磁盘组有真实空间。
