ORA-01033在RAC环境下本质是PDB未OPEN，即目标PDB在部分节点处于MOUNTED状态而非READ WRITE/READ ONLY，负载均衡路由至该节点时触发报错；需逐节点执行ALTER PLUGGABLE DATABASE pdb_name OPEN或用srvctl modify pluggable database -openmode READ_WRITE -force统一生效，并验证lsnrctl status中服务注册及gv$pdbs中各inst_id下open_mode均为非MOUNTED。
ORA-01033在RAC环境下本质是PDB未OPEN
ORA-01033在RAC中几乎从不表示整个CDB卡在启动/关闭流程里，而是某个PDB（可插拔数据库）在目标节点上处于MOUNTED状态，而非READ WRITE或READ ONLY。客户端通过服务名连接时，负载均衡可能路由到该PDB尚未打开的节点，于是报错。
为什么RAC节点间PDB状态不同步
RAC中每个节点独立管理本地PDB实例，ALTER PLUGGABLE DATABASE ... OPEN只影响当前节点。常见触发场景包括：
- 手动在节点1执行了
ALTER PLUGGABLE DATABASE pdb1 OPEN，但忘了在节点2执行相同命令 - 节点2因异常重启后，PDB默认保持
MOUNTED，不会自动OPEN - 使用
srvctl启停服务时未指定-node参数，导致操作未覆盖全部节点
快速确认和修复步骤
登录任意节点的CDB$ROOT，检查PDB状态：
SELECT name, open_mode FROM v$pdbs;
若发现目标PDB在部分节点为MOUNTED，则逐个节点执行：
ALTER PLUGGABLE DATABASE <pdb_name> OPEN;
或统一用srvctl（需在grid用户下）：
srvctl modify pluggable database <pdb_name> -openmode READ_WRITE -force
注意：-force参数会强制在所有节点生效，避免遗漏。
容易被忽略的监听和服务注册问题
即使PDB已OPEN，如果监听未正确注册该PDB的服务名，客户端仍可能收到ORA-01033。检查方式：
- 在对应节点运行
lsnrctl status，确认输出中有类似Service "pdb1.example.com" has 1 instance(s)的条目 - 若缺失，执行
ALTER SYSTEM REGISTER;触发动态注册 - 不要依赖tnsping成功就认为服务可用——它只测监听通，不验证PDB实际OPEN状态
真正关键的是PDB在具体节点上的open_mode值，不是监听是否在线，也不是CDB整体状态。
