root.sh必须串行执行，先节点1待成功（crsctl check crs返回crs-4638）再节点2；共享磁盘须udev统一命名、权限为0660且路径一致；ocr/voting disk磁盘组必须用normal/high冗余、至少3块盘。
root.sh 必须串行执行，不能两个节点同时跑
Oracle 19c RAC 中 root.sh 不是“各跑各的”，它会跨节点同步 OCR、启动 CSSD、注册集群资源。并行执行大概率卡在 CRS-2672: attempting to start 'ora.cssd' 或直接报 ORA-15018: diskgroup cannot be created。
- 严格按顺序：先节点1，等看到
Successfully configured Oracle Grid Infrastructure和clscfg: EXISTING configuration version 5 detected日志再切到节点2 - 节点1执行完必须验证：
crsctl check crs返回CRS-4638: Oracle High Availability Services is online - 别信图形界面的“自动执行”勾选项——SSH 超时或权限问题会导致它静默失败
- 执行前确认两节点
/etc/oratab中 grid 条目一致：grid:/u01/app/19.3.0/grid:N（末尾是N，不是Y）
ASM 磁盘识别失败？先查 udev 权限和路径一致性
执行 asmcmd lsdsk 返回空，或 root.sh 卡在 CLSRSC-4002 后无响应，90% 是磁盘没被 ASM 正确识别。
- 共享磁盘路径必须完全一致：节点1是
/dev/oracleasm/disks/DISK1，节点2不能是/dev/sdb—— 统一用 udev 绑定固定名 - udev 规则必须含三要素：
OWNER="grid"、GROUP="asmadmin"、MODE="0660"（缺一不可，MODE="660"无效） - 执行
udevadm control --reload-rules && udevadm trigger后，用ls -l /dev/oracleasm/disks/*实际检查属主是否已变 - 若用 NVMe 盘（如
/dev/nvme0n1），udev 匹配条件要写成SUBSYSTEM=="block", KERNEL=="nvme[0-9]n[0-9]"，不能套 SCSI 的sd*模式
OCR/Voting Disk 至少要 3 块盘，EXTERNAL REDUNDANCY 不行
19c 强制要求 OCR 和 Voting Disk 所在磁盘组必须满足冗余容错能力，哪怕你只建单节点 GI，也不能用 EXTERNAL REDUNDANCY 配 OCR 盘。
- 创建 OCR 磁盘组时，必须选
NORMAL或HIGH冗余；EXTERNAL仅适用于 DATA/FRA 这类业务磁盘组 -
NORMAL冗余至少需要 3 块盘（奇数），且每块盘容量一致；少于 3 块会直接报ORA-15018，无法回退 - 验证命令：
ocrcheck -config和votectl query，两者都必须显示状态为ONLINE - 如果误用 EXTERNAL 创建了 OCR 盘，只能清空所有配置重来——没有在线修复手段
crsctl start crs 卡在 CRS-4124？先看 root 用户对 /dev/oracleasm 的权限
现象是 crsctl start crs 返回成功，但 crsctl check crs 显示 CRS-4639: Could not contact Oracle High Availability Services，日志里反复刷 CRS-4124。
- 第一排查点：
$GRID_HOME/log/$(hostname)/agent/crsd/orarootagent_root/orarootagent_root.log，搜ORA-或Failed to initialize，90% 是 root 用户无权读/dev/oracleasm - 第二验证点：
su - oracle -c "asmcmd lsdg"，如果报ASMCMD-08102: no connection to ASM，说明 +ASM 实例根本没起来，去查$GRID_HOME/log/$(hostname)/asm/alert_+ASM.log - 常见真凶：oracle 用户的
ORACLE_HOME指向数据库软件而非 GI 软件，导致它连不上 +ASM - 注意：SELinux 必须禁用，否则
orarootagent会被拦截，setenforce 0不能只临时设，要写进/etc/selinux/config
实际部署中最容易被跳过的，是节点间 /etc/hosts 的双向解析一致性，以及 chronyd 的 makestep 1.0 -1 配置——时间差超 1 秒，cluvfy stage -pre crsinst 就会直接失败，但错误信息藏在日志深处，不翻就找不到。
