oracle rac中i/o等待严重时，根源常是asm磁盘组条带化配置未对齐底层存储能力，需检查au大小、failgroup物理隔离性及节点间asm一致性，再针对性重建磁盘组。
oracle rac中i/o等待严重时，先确认是不是asm层的条带化配置不当
很多rac集群在负载上升后出现大量 enq: hs - contention、db file sequential read 或 direct path read 等待，表面看是i/o慢，但根源常在asm磁盘组的条带化策略没对齐底层存储能力。asm默认的细粒度条带（128kb）在高并发小io场景下可能引发热点盘争用，尤其当磁盘组由少量大容量盘（如4tb sas盘）组成时。
判断依据：select group_number, name, allocation_unit_size, sector_size from v$asm_diskgroup 查看AU大小；再结合 select path, state, mode_status, failgroup from v$asm_disk 看盘分布是否均衡。若同一FailGroup内多块盘挂载在同一物理控制器或同一RAID LUN上，条带再细也白搭。
调整ASM磁盘组条带化：不是调au_size，而是选对COMPATIBLE.ASM和条带类型
ASM不提供运行时修改条带粒度的命令，所谓“优化条带化”本质是重建磁盘组时指定合理参数。关键不是盲目增大AU（比如设成4MB），而是匹配业务IO特征：
- OLTP为主（大量随机小IO）：保持默认
au_size=1MB，启用细粒度条带（ATTRIBUTE 'compatible.asm'='12.1.0.0'及以上，默认开启） - DSS/报表类（大顺序读）：可设
au_size=4MB，减少元数据开销，但需确保所有磁盘性能一致，否则易出现“木桶效应” - 混合负载：优先保障FailGroup间物理隔离，比调AU更重要——比如用6块盘建2个FailGroup（3+3），比单FailGroup 6块盘更能分散IO压力
重建示例：
CREATE DISKGROUP dg_data NORMAL REDUNDANCY<br> FAILGROUP fg1 DISK '/dev/oracleasm/disks/DISK01'<br> FAILGROUP fg2 DISK '/dev/oracleasm/disks/DISK02'<br> ATTRIBUTE 'compatible.asm'='19.0.0.0', 'au_size'='1M';
检查并规避常见ASM条带化陷阱
这些配置错误会让条带化失效，甚至加剧I/O倾斜：
- 磁盘路径命名无规律（如
/dev/sdb,/dev/sdc），导致OS层IO调度器将多个ASM盘映射到同一HBA通道——用ls -l /dev/disk/by-path/核对物理路径是否真正分散 - 启用了
disk_repair_time但未监控磁盘状态，一块盘降级后IO被强制重定向到同FailGroup其余盘，条带变“伪条带” - 误以为
cell.smart_scan_capable=true能绕过ASM条带问题——Exadata智能扫描只加速SQL层，底层ASM IO路径照旧受条带策略约束 - 使用ASMLIB而非UDEV管理设备，导致重启后盘序变化，ASM自动重新平衡时产生大量跨盘迁移，期间I/O等待飙升
RAC环境下必须同步验证节点间ASM实例行为一致性
单节点调优没用。两个关键点常被忽略：
- 所有节点的
asm_power_limit必须相同（默认1），否则某节点发起rebalance时，其他节点可能因参数低而无法及时参与，造成IO堆积在未完成平衡的磁盘上 -
v$asm_client中各节点连接的instance_name和db_name必须与CRS注册信息一致，否则OCR中记录的磁盘组依赖关系错乱，节点重启后可能挂载失败，触发全量发现流程，放大I/O压力 - 检查
crsctl stat res -t | grep asm确保每个节点的ASM实例状态为ONLINE，且没有INTERMEDIATE状态残留（说明上次rebalance异常中断）
真正的瓶颈往往不在条带宽度，而在FailGroup拓扑是否真实反映物理隔离，以及RAC各节点对ASM资源的协同是否干净。重建磁盘组前，先用 asmcmd ls -l 和 iostat -x 1 5 在各节点分别采样，比直接调参更管用。
