oracle 11g rac升级后无法启动，主因是源库补丁级别不达标或ocr/voting disk节点清单状态不一致；须验证源版本是否满足最低要求（如10.2.x需≥10.2.0.2）、ocr配置与voting disk路径跨节点完全一致，并确保所有节点均在ocr白名单中。
oracle 11g rac 升级后无法启动，大概率不是“启动命令没敲对”，而是源库补丁级别不达标或节点清单（ocr/voting disk）状态不一致——这两点只要一个没过，crsctl start crs 就会卡在 ohasd.bin 或直接报 crs-4639。
检查源数据库是否满足最低补丁集要求
11g 第2版（11.2.x）只接受特定版本+补丁集的升级入口。低于这些门槛，升级程序可能“静默跳过”校验，但集群服务根本拉不起来。
- 从 9.2.x 升级：必须是
9.2.0.8或更高；低于此值，catupgrd.sql会失败，但更常见的是 GI 层启动时cssd因 OCR 兼容性拒绝初始化 - 从 10.1.x 升级：必须是
10.1.0.5；若为10.1.0.4，需先打补丁再升级，否则rootupgrade.sh执行后ocrconfig -showbackup可能报错找不到有效备份 - 从 10.2.x 升级：必须是
10.2.0.2；注意10.2.0.1是明确不被支持的起点，强行升级会导致 Voting Disk 格式识别失败，crsctl check cluster -all显示部分节点 “Node is not online” - 从 11.1.x 升级：必须是
11.1.0.6；低于此值，ohasd.bin启动后会反复 forkcssdmonitor然后崩溃，tail -f $GRID_HOME/log/*/cssd/ocssd.log里会出现 “Invalid version in OCR header”
验证 OCR 和 Voting Disk 是否跨节点一致
升级过程若中断或某节点未完成 rootupgrade.sh，OCR 内容可能停留在旧版本，而 Voting Disk 的 disk header 版本又不匹配，导致节点间“互相不认”。这不是权限或网络问题，是元数据层面的撕裂。
- 用
ocrcheck -config在每个节点分别执行，确认输出中Device/File Name完全一致，且Cluster registry integrity check succeeded出现在所有节点日志末尾 - 用
crsctl query css votedisk检查 Voting Disk 路径是否全部指向共享存储同一组 LUN（如/dev/mapper/vote01），而非某节点误指向本地磁盘 - 如果某节点返回
PROT-602: Unable to open the OCR file，不要急着修文件权限——先用dd if=/dev/zero of=/dev/mapper/vote01 bs=1M count=10清空该盘再重建（仅限测试环境），生产环境应从最近 OCR 备份恢复：ocrconfig -restore /u01/app/11.2.0/grid/cdata/rac-cluster/backup00.ocr
排查节点清单（Node List）在 OCR 中是否完整
升级脚本有时只更新了部分节点的 OCR 注册信息，造成新 GI 认为“只有两个节点在线”，而第三个节点因不在清单里被拒绝加入，表现为 crsctl check cluster 在节点3上始终报 CRS-4638 失败。
- 用
olsnodes -n -p -i查看当前 OCR 记录的节点名、编号、私网 IP；对比/etc/hosts和$GRID_HOME/crs/install/s_crsconfig_<hostname>.env</hostname>中的节点定义是否逐字匹配（包括大小写和域名后缀） - 若发现缺失，用
crsctl add node -n <node3_name> -i <private_ip> -o <grid_home_path></grid_home_path></private_ip></node3_name>手动添加，但前提是该节点的ohasd已运行且能访问 OCR 设备 - 切勿在 OCR 不稳定时运行
cluvfy stage -post hwos -n all——它会因读取 OCR 超时而假阳性报错，干扰判断
补丁级别和节点清单这两块，一个管“能不能进大门”，一个管“进门前要不要核对工牌”。漏掉任一环节，集群就停在启动第一秒，连 cssd 都不会真正初始化。别急着翻 crsd.log，先确保 OCR 可读、Voting Disk 可写、所有节点都在 OCR 的白名单里——这是所有后续诊断的前提。
