Oracle 19c RAC Grid软件损坏导致节点不可用问题排查与修复

Grid软件损坏后的正确修复方案：切勿硬启，避免误判故障

一旦Grid软件发生损坏，RAC节点便无法正常恢复运行。此时千万不要尝试通过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 ：如果能够顺利通过，说明操作系统层和网络没有问题，问题锁定在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。