REBALANCE引发I/O抖动是因为AU搬运与业务I/O争抢同一物理路径资源；asm_power_limit仅控制ARBx并发数，不改变单次I/O大小或规避存储延迟，设为11时若存储%util>95%或await>20ms，抖动必然放大。
为什么REBALANCE会引发I/O抖动？不是参数调高了就一定快
asm磁盘组平衡（rebalance）期间的i/o抖动，本质是au（allocation unit）搬运过程与业务i/o争抢同一套物理路径资源。关键点在于：asm_power_limit只控制arbx进程并发数，不改变单次i/o大小、不绕过存储延迟、也不规避底层设备排队。当设为11时，理论i/o请求数可比1翻10倍以上，但若存储本身%util > 95%或await > 20ms，抖动必然放大。
常见误判：看到v$asm_operation里EST_MINUTES没降，就猛提asm_power_limit——其实EST_WORK和SOFAR长期不动，大概率卡在磁盘异常（如STATE=MISSING）、路径中断或LUN屏蔽，而非“不够快”。
如何避免全局改参导致全集群I/O雪崩
在RAC环境中，直接ALTER SYSTEM SET asm_power_limit=11会让所有节点同时以最高并发发起搬运，极易压垮共享存储。更稳妥的做法是按需、限时、限范围控制：
- 用
ALTER DISKGROUP dg_name REBALANCE POWER N WAIT替代全局参数调整，操作结束自动恢复默认值 - 避开业务高峰，尤其注意RAC中
gv$asm_operation显示多个节点STATE=RUN时，I/O压力是叠加的 - 全闪存阵列可试6–8；混闪或机械盘建议≤4，并配合
iostat -xm 1盯%util和await -
POWER=0不能暂停正在运行的平衡，它只禁止新平衡启动；真要中止，必须用ALTER DISKGROUP dg_name STOP REBALANCE
检查是否被兼容性或显式POWER子句“暗中覆盖”
你设了asm_power_limit=8，但v$asm_operation里POWER列始终是2？说明这次REBALANCE执行时带了POWER 2子句，优先级高于实例参数。同样，若磁盘组COMPATIBLE.ASM='11.2.0.2'，哪怕设100，ASM也只按上限11执行。
确认方式必须查两个视图：
-
SELECT inst_id, name, value FROM gv$parameter WHERE name = 'asm_power_limit'—— 看各节点实际生效值 -
SELECT inst_id, operation, state, power, sofar, est_work FROM gv$asm_operation—— 看当前运行中的操作真正用了多少并发度
真正缓解抖动，得从源头隔离I/O路径
平衡抖动难治，常因底层未做物理隔离：比如6块盘全在一个FailGroup，或全部挂载在同一HBA通道下，再细的条带也白搭。此时调asm_power_limit只是让争抢更剧烈。
实操重点不在“加速搬运”，而在“减少冲突”：
- 用
ls -l /dev/disk/by-path/核对ASM磁盘是否真正分散在不同物理路径（别只看/dev/sdb这种命名） - FailGroup设计优先于AU大小：OLTP场景下，3+3（两组各3盘）比单组6盘更能分摊随机IO压力
- 禁用
disk_repair_time后未监控状态，一块盘降级会强制IO重定向到同FailGroup其余盘，等于人为制造热点
平衡任务本身无法消除I/O抖动，它只是把数据从一处搬到另一处；抖动是否可控，取决于你有没有提前把磁盘、控制器、路径这三层物理资源真正切分开。
