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。
