ORA-01033在RAC环境中表示至少一个节点卡在MOUNT或更早阶段，非单实例的临时等待问题；需通过crsctl、v$instance和告警日志定位卡住实例，排查控制文件、redo日志或数据文件异常，并检查SCAN监听注册状态。
ORA-01033在RAC环境里意味着什么
不是单实例那种“等几分钟就好”的状态，而是至少有一个节点卡在 MOUNT 或更早阶段，导致整个集群无法对外提供连接。RAC下出现 ORA-01033 通常说明：某个实例没完成 OPEN，或者 CRS 没正确拉起所有资源，客户端却尝试连到了这个“半开”实例上。
先确认哪个实例挂住了
别急着 shutdown 或 startup，先看真实状态：
- 用
crsctl stat res -t查所有数据库资源是否 ONLINE，重点关注ora.<db_name>.db和各节点上的ora.<db_name><n>.inst - 登录任一节点，执行
sqlplus / as sysdba，然后跑select instance_name, status, database_status from v$instance;—— 如果status是MOUNTED而非OPEN，就是它卡住了 - 查该实例的告警日志：
$ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/alert_<instance_name>.log，重点搜ORA-、error、recover这些词
RAC节点卡在MOUNT状态怎么救
常见原因是控制文件、redo 日志或数据文件异常（比如磁盘离线、权限错、路径变更），导致实例无法完成 OPEN 阶段的实例恢复。操作必须在对应节点上做：
- 确保当前 shell 的
ORACLE_SID设置正确，比如export ORACLE_SID=wpsdb1 - 运行
sqlplus / as sysdba，执行startup mount—— 如果失败，说明 NOMOUNT 都过不去，得先检查 spfile/pfile、密码文件、监听配置 - 如果
startup mount成功但alter database open;报错，大概率是 redo 或 datafile 问题。例如报ORA-00313，就用select group#, status, member from v$logfile;看哪组日志坏了，再用alter database clear logfile group <n>;清掉（仅限非归档模式且无未提交事务时） - 如果报
ORA-01157找不到数据文件，先确认文件路径是否真实存在、权限是否为 oracle:oinstall、ASM diskgroup 是否 online；若文件确实丢失且无备份，只能alter database datafile <n> offline drop;（慎用，会丢数据）
别忽略CRS和SCAN监听的影响
RAC里客户端连的是 SCAN VIP，背后由监听器路由到具体实例。如果某个实例虽然 OPEN 了，但没注册进 SCAN 监听，客户端仍可能被分发到一个刚启动还没来得及注册的实例上，触发 ORA-01033：
- 在出问题节点上运行
lsnrctl status LISTENER_SCAN1（或对应 SCAN 监听名），看输出里有没有该实例的 service name - 如果没有，手动注册：
srvctl modify instance -d <db_name> -i <instance_name> -s <service_name>，再执行srvctl start instance -d <db_name> -i <instance_name> - 极端情况下，直接重启 SCAN 监听：
srvctl stop scan_listener→srvctl start scan_listener
真正麻烦的从来不是命令敲不对，而是卡住的节点背后藏着 ASM 磁盘组不可用、OCR 损坏、或是某块存储突然掉线——这些不会直接报 ORA-01033，但会让实例永远停在 MOUNT。动手前务必先看告警日志第一行错误，而不是反复试 startup。
