ASMLib 在 Oracle 19c RAC 中已被官方弃用，启用会导致 ASM IO 性能严重下降甚至集群宕机；必须停用并清除内核模块、磁盘头残留，切换至 ASMFD，并确保 FAILGROUP 分布、asm_power_limit 和 OCR 磁盘组配置合理。
ASMLib 在 Oracle 19c RAC 中不仅不解决问题，反而会直接导致 ASM 磁盘 IO 性能严重下降，甚至引发集群宕机。它早已被 Oracle 官方彻底弃用，任何在 19c 环境中启用或残留 ASMLib 的行为，都是性能问题的第一嫌疑对象。
确认 ASMLib 是否仍在运行 —— 先停，再查
不要假设它没启，生产环境里常有历史配置残留。最直接的验证方式是检查内核模块和磁盘头状态：
-
lsmod | grep oracleasm：若输出非空，说明内核模块已加载——这在 RHEL8+/OEL8+ 上本不该发生，但若手动编译过，就会埋雷 -
kfed read /dev/mapper/mpatha | head -20：若看到AFD相关签名（如afd_disk）被覆盖或报KFED-00322: Invalid OSM block type，基本可断定ASMLib曾写入磁盘头并破坏了 AFD 元数据 -
asmcmd afd_lsdsk输出为空或大量?状态，而ls -l /dev/mapper/asm*权限正常，大概率是ASMLib干扰了 AFD 设备识别
为什么 ASMLib 会让 ASM IO 变慢
它不是“慢”，而是“错乱”——根本不在同一套 I/O 路径上工作：
-
ASMLib绕过 Linux 块设备层，走自定义驱动路径，与ASMFD的内核过滤逻辑冲突，导致每次 I/O 都触发双重校验或重定向 - 多路径设备（如
/dev/mapper/mpatha）被ASMLib强制识别为/dev/oracleasm/disks/DISK01后，实际 I/O 仍经 multipath 走底层多条 SCSI 路径，但 ASM 元数据却认为这是单路径设备，失去故障切换能力 - RAC 节点间看到的磁盘名不一致（比如节点1是
Disk01，节点2是DiskA），触发持续的 ASM 自动重平衡（REBAL），产生巨量无效元数据同步流量，压垮控制文件和 ASM 实例内存
清理 ASMLib 并切换到 ASMFD 的关键动作
这不是“卸载软件”那么简单，必须清除所有残留痕迹：
- 在所有节点执行：
oracleasm disable && oracleasm exit && rmmod oracleasm 2>/dev/null；确认lsmod | grep oracleasm无输出 - 清空磁盘头残留：
dd if=/dev/zero of=/dev/mapper/mpatha bs=4096 count=100（仅对未挂载、无数据的盘操作；若已用于磁盘组，请跳过此步，改用重建） - 删除旧规则：
rm -f /etc/udev/rules.d/99-oracle-asm.rules和所有含oracleasm的 udev 文件 - 启用 AFD：
asmfd -i→crsctl start resource ora.asmfd→asmcmd afd_lsdsk应显示状态为a（available） - 若仍不识别，检查：
scsi_id -g -u -d /dev/sda输出的 WWID 是否与/etc/multipath.conf中wwid字段完全一致（含大小写、空格、换行）
容易被忽略的“软性卡顿”点
即使 AFD 启动成功，IO 性能仍可能卡在隐性环节：
- 磁盘组
FAILGROUP分布物理上未隔离：比如 6 块盘全挂在同一台存储控制器下，AFD 再好也变不出并发——必须用v$asm_disk查failgroup，再结合multipath -ll核对后端路径是否真正分散 -
asm_power_limit被设为过高值（如 11），且未配WAIT，一次添加磁盘就触发全盘重平衡，I/O 持续打满；应改用ALTER DISKGROUP DATA REBALANCE POWER 3 WAIT - OCR/Voting Disk 所在磁盘组使用了小 AU（如 1MB）但混在大 IO 负载盘中，控制面争用加剧；建议单独划出低负载、高可靠性的小盘建
CRS磁盘组，AU 设为 4MB
