root.sh脚本必须严格按节点顺序串行执行，先完成节点1并验证crs在线及ocr配置成功后，再执行节点2；若并行执行易导致cssd卡死、ocr初始化失败或asm磁盘组创建异常。
root.sh 脚本必须按顺序在节点间串行执行
oracle 19c rac 中 root.sh 不是“每个节点自己跑完就完事”的脚本，它会触发集群资源注册、ocr 同步、asm 实例启动等跨节点操作。如果两个节点同时运行 root.sh，极大概率出现 crs-2672: attempting to start 'ora.cssd' 卡死、ora-15018: diskgroup cannot be created 或 ocr 初始化失败。
实操建议：
- 严格按安装向导提示的节点顺序执行（通常是先配置的主节点优先）
- 节点1执行完并看到
Successfully configured Oracle Grid Infrastructure和clscfg: EXISTING configuration version 5 detected日志后，再 ssh 到节点2执行 - 执行前确认
crsctl check crs在节点1已返回CRS-4638: Oracle High Availability Services is online - 不要依赖图形界面的“自动执行”勾选——测试环境里它常因 SSH 超时或权限问题静默失败
执行前必须验证 /etc/oratab 和环境变量一致性
root.sh 会读取 /etc/oratab 中的 ORACLE_HOME 条目，并调用 $ORACLE_HOME/bin/oraenv 加载环境。若节点间 ORACLE_HOME 路径不一致、或 /etc/oratab 缺失 grid 条目，脚本会在 “Relinking oracle with rac_on option” 阶段报错 ORA-01034: ORACLE not available 或直接退出。
检查项：
- 两节点都存在且内容一致：
grid:/u01/app/19.3.0/grid:N（注意末尾是N，不是Y） -
su - grid -c "echo \$ORACLE_HOME"输出路径与/etc/oratab中完全一致（含大小写、符号） -
ls -l $ORACLE_HOME/bin/oraenv确认可执行，且属主为grid:oinstall
常见卡点：CLSRSC-4002 和 ASM 磁盘组挂载失败
执行 root.sh 时卡在 CLSRSC-4002: Successfully installed the CSI agent 后长时间无响应，或后续报 ORA-15032: not all alterations performed，基本指向 ASM 磁盘识别或权限问题。
原因与应对：
- 共享磁盘未在两节点用相同路径（如
/dev/oracleasm/disks/DISK1vs/dev/sdb）——统一用 udev 绑定固定名，别信fdisk -l的临时设备名 - 磁盘权限不对：
chown grid:asmadmin /dev/oracleasm/disks/*必须在两节点都执行，且asmadmin组要包含 grid 用户（id grid验证） - OCR 磁盘组创建时用了
EXTERNAL REDUNDANCY但只提供 1 块盘——19c 强制要求 OCR/Voting Disk 至少 3 块盘（Normal 冗余），否则root.sh无法完成 CRS 注册
执行后必须立即验证集群资源状态
root.sh 成功返回不等于集群可用。很多故障（比如 SCAN VIP 漂移、GIMR 数据库未启动）要等 2–3 分钟才暴露。
关键验证命令（在任一节点执行）：
-
crsctl stat res -t：重点看ora.asm、ora.crsd、ora.scan*.vip是否 ONLINE；若ora.gimr.db是 INTERMEDIATE，说明 MGMTDB 未就绪，需手动srvctl start mgmtdb -
ocrcheck：输出中Status必须为SUCCESS，且Version显示 19c 对应版本（如5） -
asmcmd lsdg：确认 OCRDG、DATADG 等磁盘组State为MOUNTED，Offline Disks为 0
最容易被忽略的是：即使所有资源显示 ONLINE，SCAN DNS 解析失败也会导致客户端连接超时。务必用 nslookup your-scan-name 确认能解析出全部 3 个 SCAN IP，且这些 IP 已在两节点的 /etc/hosts 中静态绑定（RAC 环境严禁依赖动态 DNS）。
