必须启用disk.EnableUUID="TRUE"，否则scsi_id无法获取唯一UUID导致ASM识别失败；需在两节点.vmx中添加该行、关机重启后验证scsi_id输出一致，并用udev规则绑定原始块设备为/dev/asm-diskX。
scsi_id 拿不到 UUID？先查 disk.EnableUUID 是否启用
VMware 环境下，scsi_id -g -u -d /dev/sdb 返回空或重复值，基本就是 disk.EnableUUID = "TRUE" 没生效。这不是权限或路径问题，而是 VMware 层面的磁盘元数据开关未打开。
- 必须编辑每个节点的
.vmx文件，手动添加一行：disk.EnableUUID = "TRUE" - 关机重启虚拟机（不能仅重启 OS），否则设置不加载
- 验证方式：在两个节点上对同一块共享盘（如
/dev/sdb）分别执行scsi_id -g -u -d /dev/sdb，输出必须是**完全相同的 33 位字符串**（如3613e0937b040da0801c0cd8afee9a263） - 若不一致，说明要么不是真正共享盘，要么 VMware 设置未生效，后续所有 udev 绑定都会错乱
udev 规则写在哪、怎么写才不静默失效
规则文件位置、路径、语法稍有偏差，udevadm trigger 就会静默跳过，设备节点根本不会生成。
- 规则文件必须放在：
/etc/udev/rules.d/99-oracle-asmdevices.rules（编号建议 ≥99，确保优先级） -
scsi_id路径在 CentOS 7+ 是/usr/lib/udev/scsi_id，不是/sbin/scsi_id—— 写错路径会导致PROGRAM执行失败，RESULT匹配永远为空 - 推荐直绑原始块设备（不分区），规则示例：
KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$name", RESULT=="3613e0937b040da0801c0cd8afee9a263", SYMLINK+="asm-diskb", OWNER="grid", GROUP="asmadmin", MODE="0660" - 不要用
sd?1（分区后设备），Oracle 官方明确反对 ASM 磁盘预先分区；分区后asmcmd lsdsk -k可能显示为CANDIDATE但无法加入磁盘组
udev 重载后 /dev/asm-disk* 没出来？检查这三步
规则写了、udevadm control --reload 也执行了，但 ls /dev/asm* 仍为空——大概率卡在这几个环节。
- 必须成对执行：
udevadm control --reload+udevadm trigger --type=devices --action=change；只 reload 不 trigger，规则不会应用到已存在的设备 - 两个 RAC 节点都要单独执行，缺一不可；少一个节点，ASM 实例启动时直接报
ORA-15032或找不到磁盘 - 验证
scsi_id是否真能跑通：sudo -u grid /usr/lib/udev/scsi_id -g -u -d /dev/sdb（模拟 udev 上下文权限）；若仍为空，回头检查disk.EnableUUID和磁盘是否真的被识别为共享
OCR/Voting Disk 和 DATA 磁盘组必须物理隔离
很多人把 OCR、Voting Disk 和 DATA 全部塞进同一个 ASM 磁盘组，安装看似成功，但集群服务极其脆弱，稍有 IO 波动就可能脑裂或 CRS 无法启动。
- OCR 和 Voting Disk 必须使用独立的物理磁盘（至少 3 块），且不能与 DATA 混用；官方最低要求是 Normal 冗余需 3 块盘，External 冗余可 1 块但不推荐
- 命名要区分：例如 OCR 盘绑定为
/dev/asm-ocr1，DATA 盘为/dev/asm-data1，避免 asmca 误选 - 切忌用同一块盘的不同分区做 OCR 和 DATA —— ASM 不禁止，但 RAC 集群仲裁机制会失去容错能力，这不是配置错误，而是架构风险
实际部署中最容易被忽略的是：disk.EnableUUID 必须在关机后生效，而多数人习惯热添加磁盘后只重启系统；还有就是 udev 规则里 /usr/lib/udev/scsi_id 的路径，在不同发行版中位置不一致，CentOS 7/8 和 Oracle Linux 8 都在此，但 RHEL 9 已移至 /usr/bin/scsi_id，得按实际环境核对。
