根本原因是ASM实例未识别磁盘：asmcmd lsdsk -k无输出表明设备路径未被扫描到，须先验证内核路径一致性、检查udev规则与asm_diskstring配置（19c需显式设置并加SID='*'），再确认节点间设备路径、WWID、权限及AFD接管状态完全一致。
Oracle 19c RAC中ASM磁盘组无法自动挂载，根本原因不是“没配置自动挂载”，而是ASM实例压根没识别到磁盘——自动挂载的前提是磁盘组在启动时已存在于v$asm_diskgroup中，而它为空，就注定不会挂。
asmcmd lsdsk -k 无输出：ASM连磁盘设备路径都没扫到
这是最常被跳过的起点。执行asmcmd lsdsk返回空或报ORA-15033，说明ASM实例虽在运行，但未发现任何块设备。此时ALTER DISKGROUP ... MOUNT必然失败，因为无盘可挂。
- 立刻加
-k参数重试：asmcmd lsdsk -k，它强制走内核设备路径，能暴露节点间路径不一致（如节点1是/dev/mapper/DATA01，节点2是/dev/sdb） - 若仍无输出，检查
/etc/udev/rules.d/99-asm-disk.rules是否存在且生效；执行udevadm trigger --subsystem-match=block和udevadm control --reload-rules - 所有节点上必须保证
ls -l /dev/mapper/ | grep data和blkid | grep -i data输出完全一致——差一个字符，CRS就无法协调
asm_diskstring未显式设置或SID='*'缺失
19c默认asm_diskstring为NULL，理论上会扫描所有块设备，但实际在RAC中极易因权限、规则或multipath干扰失效。不显式指定，等于让ASM“闭眼找盘”。
- 查当前值：
SHOW PARAMETER asm_diskstring；常见错误包括留空、写成ORCL:*（ASMLIB已弃用）、或只设了单节点 - 安全写法是逗号分隔、无空格、指向真实UDEV别名，例如：
'/dev/mapper/datap1','/dev/mapper/datap2' - RAC中必须加
SID='*'：执行ALTER SYSTEM SET asm_diskstring='...' SCOPE=BOTH SID='*'，否则仅当前节点生效
v$asm_disk中path匹配但header_status异常
当asmcmd lsdsk有输出，但asmcmd lsdg看不到磁盘组，或挂载时报ORA-15040、ORA-15042，说明磁盘被识别，但头部不可读或未组成有效组。
- 连
sqlplus / as sysasm查SELECT path, header_status FROM v$asm_disk WHERE path LIKE '%datap1%'；若为CANDIDATE或FORMER，大概率是磁盘头magic损坏（KFED-00322），不是数据丢失 - 确认设备属主和权限：
ls -l /dev/mapper/datap1必须是grid:asmadmin且权限为brw-rw----（即0660） -
/etc/sysconfig/oracleasm中ORACLEASM_UID和ORACLEASM_GID也需与之匹配，改完必须oracleasm force-scandisks再scandisks
AFD未接管或repair后未验证状态
即使用kfed repair修复了磁盘头，若AFD（ASM Filter Driver）未接管该盘，ASM实例依然看不见它——这是修复后仍挂载失败的最隐蔽原因。
-
kfed repair必须显式指定ausz参数（如AU=4M时填4194304），填错会导致后续挂载直接拒绝 - 修复后立即验证：
kfed read /dev/mapper/DATA01 | egrep 'kfbh.type|dsknum|grpname'，确保kfbh.type = KFBTYP_DISKHEAD且dsknum、grpname与原盘一致 - 最关键一步：执行
asmcmd afd_lsdsk，确认该盘状态为a（active），否则ALTER DISKGROUP MOUNT只是对空气操作
