如何修复Oracle 19c RAC Grid软件损坏导致节点不可用

Grid软件损坏后的正确修复姿势：别硬拉，也别误判故障

Grid软件一旦损坏，节点将彻底无法恢复运行。此时切勿尝试通过crsctl start crs或srvctl start instance强制启动——底层依赖如ohasd、ora.asm已经断裂，硬拉只会加剧问题。正确的修复流程是“删除故障节点→重装GI→添加节点”，每个步骤缺一不可。

确认Grid软件是否真损坏，别把权限/路径问题当崩溃

很多时候，“Grid损坏”其实是误判。例如/etc/oracle/olr.loc指向错误、$GRID_HOME目录权限被改为777、或grid用户环境变量丢失，这些都会导致静默失败，但Grid软件本身并未损坏。

• 先检查ps -ef | grep ohasd：如果没有输出，说明不是OLR损坏，而是ohasd未启动。此时应查看/etc/oracle/olr.loc内容是否有效，必须为olrconfig_loc=/u01/app/19c/grid/cdata/olr.ocr这样的绝对路径。
• 再看$GRID_HOME/log//client/ocrcheck.log：如果出现ORA-15077: cannot locate ASM instance serving OCR，才指向OLR本体损坏。若仅出现PRCR-1076或CRS-4535，大概率是OCR访问链路中断——例如ASM未启动、监听未启动或密码文件缺失。
• 执行cluvfy stage -pre crsinst -n ：能成功运行，说明OS层和网络无问题，问题锁定在GI安装态本身。

删除故障节点前，必须在正常节点上完成三步清理

直接在故障节点上执行rm -rf $GRID_HOME会留下OCR残留，后续添加节点必然失败。所有关键操作必须从健康节点发起。

• 以root用户在正常节点执行：/u01/app/19c/grid/bin/crsctl delete node -n （注意此处不是deconfig，这是11g的旧方法）。
• 验证清除效果：/u01/app/19c/grid/bin/olsnodes -s -t中不应再出现该节点；crsctl stat res -t | grep 应无输出。
• 手动清理故障节点上的残留：登录故障节点，执行rm -rf /u01/app/19c/grid/crs/install/*、rm -f /etc/oracle/olr.loc、rm -f /etc/oracle/ocr.loc——这些文件若存在，会干扰新GI安装。

静默添加节点时，addnode.sh参数必须严格匹配原集群

Oracle 19c已不允许使用“tar包复制+root.sh”这种粗暴方式。静默安装必须保证网络资源命名与OCR记录完全一致，否则ora.asm将卡在OFFLINE状态。

• 关键参数示例：./addnode.sh -silent -ignoreSysPrereqs "CLUSTER_NEW_NODES={node2}" "CLUSTER_NEW_PRIVATE_NODE_NAMES={node2-priv}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={node2-vip}"
• CLUSTER_NEW_NODES的值必须与olsnodes输出的节点名大小写完全一致；CLUSTER_NEW_VIRTUAL_HOSTNAMES必须与OCR中注册的VIP名一致（查询方式：srvctl config vip -n node2）。
• 执行完addnode.sh后，务必在故障节点上以root身份运行生成的rootaddnode.sh脚本——漏掉此步骤会导致ora.cssd无法注册，后续所有资源无法启动。

还原后ora.asm长期OFFLINE？重点查密码文件和监听

OLR还原成功只是第一步。ora.asm无法启动，90%的原因不在OLR，而在ASM实例自身启动失败。

• 检查$GRID_HOME/dbs/orapw+ASM是否存在，属主必须为grid:oinstall，权限必须为600。若丢失，使用orapwd重建：orapwd file=$GRID_HOME/dbs/orapw+ASM password=xxx force=y format=12
• 检查ora.LISTENER.lsnr状态：crsctl stat res ora.LISTENER.lsnr -p | grep ENDPOINTS，确保端口未被占用且监听地址绑定正确。若状态为UNKNOWN，先停再启：crsctl stop res ora.LISTENER.lsnr -f && crsctl start res ora.LISTENER.lsnr
• 查看$GRID_HOME/log//asm/alert*.log，搜索ORA-01017或ORA-12541——前者表示密码错误，后者表示监听未启动，不要一概归咎于OLR。

整个过程最容易被忽略的是rootaddnode.sh的执行时机和orapw+ASM的权限校验。很多DBA在添加节点后看到crsctl check crs返回CRS-4638就认为成功，结果crsctl stat res -t中ora.asm一直显示灰色，最终发现是密码文件属主错误，或监听未绑定到公网IP。