Oracle RAC集群节点重启后GI无法自启动怎么办-Oracle-PHP中文网

oracle rac节点重启后gi未启动的根本原因是底层状态不一致：/tmp/.oracle/残留socket或olr文件丢失导致crs无法初始化，常见报错crs-4124或crs-4535；需清理socket、验证并修复olr.loc路径，再统一设置auto_start=always，同时确保dns早于gi启动。

oracle rac集群节点重启后gi无法自启动怎么办

Oracle RAC节点重启后GI（Grid Infrastructure）没起来，**不是“没启动”，而是根本没走到启动流程——大概率是底层依赖缺失或状态不一致导致CRS服务压根无法初始化**。

ora.gipcd启动失败：先清空/proc/sys/net/core/somaxconn残留socket

常见现象是crsctl check crs返回CRS-4535: Cannot communicate with Cluster Ready Services，但crsctl stat res -t -init能看到ora.gipcd反复fail。日志里高频出现ret:gipcretKeyNotFound (36)或gipcPostF failed to post obj 0000000000000000。

这不是配置问题，是11g/12c常见残留bug：GIPCD启动时试图复用旧的IPC socket地址，但内核/proc/sys/net/core/somaxconn或/tmp/.oracle/下残留文件干扰了绑定。

停掉本地CRS：crsctl stop crs -f（必须加-f，否则可能卡住）
清理socket目录：rm -f /tmp/.oracle/*
重置网络参数（可选，但推荐）：echo 128 > /proc/sys/net/core/somaxconn
再执行crsctl start crs

OLR文件丢失：手动重建前先确认olr.loc路径

RAC 11g环境最典型死因：节点重启后crsctl start crs直接报CRS-4124: Oracle High Availability Services startup failed，且crsctl check crs显示Could not contact Oracle High Availability Services——这时/etc/oracle/olr.loc很可能指向一个已删除的.olr文件。

别急着重建OLR，先验证路径是否真实存在：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

运行cat /etc/oracle/olr.loc，拿到olrconfig_loc=后的完整路径（比如/u01/app/11.2.0/grid/cdata/orcl02.olr）
检查该路径是否存在：ls -l /u01/app/11.2.0/grid/cdata/orcl02.olr
如果文件不存在，且你有备份（比如从正常节点scp过来），直接复制还原；没有备份则需用ocrconfig -restore配合OCR备份恢复，但前提是OCR本身完好

AUTO_START=restore导致资源“选择性不启”

GI起来了，但数据库、监听、磁盘组全offline？查crsctl status resource -t发现状态是OFFLINE，且crsctl status resource ora.<db_name>.db -p | grep AUTO_START</db_name>返回AUTO_START=restore——这就是关键。

AUTO_START=restore的意思是：“只在上次关机前是online的状态下才自动拉起”，而异常断电后CRS记录的状态极大概率是OFFLINE，于是所有资源全部跳过启动。

必须统一设为always：crsctl modify resource ora.<db_name>.db -attr "AUTO_START=always"</db_name>
同样处理监听：crsctl modify resource ora.LISTENER.lsnr -attr "AUTO_START=always"
磁盘组也别漏：crsctl modify resource ora.DATADG.dg -attr "AUTO_START=always"
注意：每个节点都要单独执行，不能只在node1改完就认为node2也生效

DNS未就绪导致SCAN解析失败（尤其19c+）

19c RAC节点重启后GI能起来，但crsctl check crs报PRVF-4664: Found inconsistent name resolution entries for SCAN name，且SCAN只解析到1个IP——这说明DNS服务比GI启动慢，或者DNS配置本身就不满足SCAN要求（必须解析出3个IP）。

这不是GI故障，是启动顺序依赖断裂：

确认DNS服务开机自启：systemctl is-enabled named（或对应DNS服务名）
临时绕过：把SCAN条目写进/etc/hosts（仅测试用，生产环境必须走DNS）
更稳妥的做法：在GI启动前插入systemd依赖，例如修改/usr/lib/systemd/system/oracle-gi.service，加After=named.service和Wants=named.service

真正卡住的地方往往不在“怎么启”，而在“为什么连初始化都失败”。OLR路径错、socket残留、DNS晚于GI启动——这些都不是配置项问题，而是环境状态问题。改完AUTO_START却仍不生效，八成是前面几步根本没过。