Grid软件损坏后必须走“删节点→重装GI→加节点”完整流程，严禁硬拉；确认是否真损坏需先查ohasd进程、olr.loc路径、ocrcheck.log错误及cluvfy验证；删除节点须从健康节点执行crsctl delete node，故障节点仅清理残留；addnode.sh参数须严格匹配OCR注册名，且rootaddnode.sh不可遗漏，ora.asm异常优先查orapw+ASM权限与监听状态。
grid软件损坏后节点无法恢复运行，不能靠crsctl start crs或srvctl start instance硬拉——因为底层依赖（如ohasd、ora.asm）已断裂，必须走“删节点→重装gi→加节点”完整流程。
确认Grid软件是否真损坏，别把权限/路径问题当崩溃
很多所谓“Grid损坏”，其实是/etc/oracle/olr.loc指向错误、$GRID_HOME目录权限被改成777、或grid用户环境变量丢失导致的静默失败。
- 先检查
ps -ef | grep ohasd：若无输出，不是OLR坏，而是ohasd根本没启动；此时应查/etc/oracle/olr.loc内容是否有效（必须是olrconfig_loc=/u01/app/19c/grid/cdata/olr.ocr这类绝对路径） - 再看
$GRID_HOME/log/<hostname>/client/ocrcheck.log：出现ORA-15077: cannot locate ASM instance serving OCR才指向OLR本体损坏；若只有PRCR-1076或CRS-4535，大概率是OCR访问链路断了（比如ASM未启、监听未起、密码文件缺失） - 执行
cluvfy stage -pre crsinst -n <node_name>：能跑通就说明OS层和网络没问题，问题在GI安装态本身
删除故障节点前，必须在正常节点上完成三步清理
直接在故障节点上rm -rf $GRID_HOME会留下OCR残留，导致后续add node失败。所有关键操作必须从健康节点发起。
- 以
root用户在正常节点执行：/u01/app/19c/grid/bin/crsctl delete node -n <faulty_node>（注意不是deconfig，那是11g老方法） - 验证清除效果：
/u01/app/19c/grid/bin/olsnodes -s -t中不应再出现该节点；crsctl stat res -t | grep <faulty_node>应无输出 - 手动清理故障节点上的残留：登录故障节点，
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/<hostname>/asm/alert*.log，搜索ORA-01017或ORA-12541——前者是密码错，后者是监听没起来，别一概归咎于OLR
整个过程最易被忽略的是rootaddnode.sh的执行时机和orapw+ASM的权限校验。很多DBA在add node后看到crsctl check crs返回CRS-4638就以为成功了，结果crsctl stat res -t里ora.asm一直灰着，最后发现是密码文件属主错了或者监听压根没绑到公网IP。
