ASM_POWER_LIMIT仅控制ARBx进程并行搬运AU的速度，不解决I/O瓶颈、兼容性限制（如COMPATIBLE.ASM=11.2.0.2时上限为11）或存储延迟；EST_MINUTES不降常因磁盘异常、I/O阻塞或POWER子句覆盖参数。
为什么asm_power_limit调高了，平衡还是慢？
不是参数没生效，而是你看到的“慢”，大概率卡在非asm_power_limit控制的环节。这个参数只影响arbx进程并行搬运au（allocation unit）的速度，但不解决磁盘i/o瓶颈、磁盘组兼容性限制、或底层存储响应延迟。比如：磁盘组compatible.asm仍是11.2.0.2，那即使设asm_power_limit=100，asm也只按11执行；又或者存储本身吞吐已饱和，再多个arbx进程也只是排队等i/o。
v$asm_operation里EST_MINUTES一直不降，说明什么？
这通常意味着估算逻辑卡住了，不是真正在搬数据。常见原因包括：
-
EST_WORK和SOFAR长期不动 → 可能磁盘状态异常（如MISSING或OFFLINE），先查v$asm_disk里STATE和HEADER_STATUS -
EST_RATE持续为0 → I/O被阻塞，检查ASMLIB或UDEV规则是否导致设备访问异常，或存储侧有LUN屏蔽/路径中断 -
POWER列显示值远低于你设置的asm_power_limit→ 说明该次REBALANCE操作显式指定了POWER子句，覆盖了实例级参数
怎么确认asm_power_limit当前生效值？
别只信show parameter asm_power_limit，它只反映当前会话或实例的设置，而RAC中各节点可能不同。必须查视图：
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;
如果power列数值稳定且等于你期望的值，说明参数已作用到本次平衡；如果为0，可能是你执行了ALTER DISKGROUP ... REBALANCE POWER 0，或磁盘组处于MOUNTED但未触发真正重平衡的状态。
调整asm_power_limit后IO飙升甚至影响业务，怎么办？
这是设计使然，不是bug。值从1升到11，理论I/O并发度可翻10倍以上，但生产环境往往扛不住。稳妥做法是：
- 优先用
ALTER DISKGROUP ... REBALANCE POWER N WAIT替代全局改参，让影响可控在单个操作内 - 避开业务高峰，尤其注意RAC中所有节点共享同一套磁盘组I/O资源
- 若存储是全闪存阵列，可尝试设到6–8；若是混闪或机械盘，建议≤4，并配合
iostat -xm 1盯%util和await - 永远不要设为0来“暂停”平衡——它只是禁止新平衡启动，对已在进行的无影响；真要停，用
ALTER DISKGROUP ... STOP REBALANCE
最常被忽略的一点：asm_power_limit调高后，ARBx进程数增加，但每个进程的I/O请求大小仍受限于_asm_ausize和底层存储块大小，所以单纯调参不等于线性提速，得看AU迁移的实际吞吐是否匹配硬件能力。
