重平衡慢主因是默认asm_power_limit=1为保业务稳定而限速，并非故障；需查gv$asm_operation确认是否真在执行、检查COMPATIBLE.ASM版本限制及底层存储I/O瓶颈。
重平衡慢不是asm坏了，而是默认的 asm_power_limit=1 故意压低了速度——它优先保业务稳定，不是性能瓶颈。
怎么确认当前重平衡卡在哪一步
别只盯着 v$asm_operation 有没有记录。先看它是否真在跑：
-
SELECT inst_id, operation, state, power, sofar, est_work FROM gv$asm_operation;—— 如果没结果，说明根本没触发重平衡（比如磁盘刚加完但还没自动启动） - 如果有记录但
power列是0，不是参数没生效，而是你或别人执行过ALTER DISKGROUP ... REBALANCE POWER 0主动挂起了它 -
state = 'EXECUTING'且sofar长期不动，大概率是底层存储响应延迟高（比如机械盘await > 50ms或全闪存阵列%util > 95%）
改 asm_power_limit 前必须查清两件事
这个参数不是设得越高越好，实际生效受 ASM 兼容性限制：
- 查磁盘组实际兼容版本：
SELECT name, compatibility, database_compatibility FROM v$asm_diskgroup;—— 如果compatibility < '11.2.0.2'，哪怕你设成1024，ASM 也只按11跑 - 查当前实例级设置：
SHOW PARAMETER asm_power_limit或SELECT name, value FROM gv$parameter WHERE name = 'asm_power_limit';—— RAC 环境中各节点可以不同，别只在一个节点上改 - 注意：修改
ALTER SYSTEM SET asm_power_limit = N是全局生效，但已开始的重平衡不会动态提速；必须用ALTER DISKGROUP ... REBALANCE POWER N才能干预正在运行的任务
生产环境推荐的取值和配套动作
没有“安全万能值”，只有匹配硬件和业务节奏的组合：
- 全闪存阵列：可试
POWER 6–8，但必须配合iostat -xm 1盯%util和await，一旦%util > 90%立即降回4 - 混闪或 SAS 机械盘：严格控制在
2–4，POWER 5+容易引发大量direct path read/write等待，拖慢数据库 SQL 响应 - 绝对不要用
POWER 0“暂停”任务——它只阻止新任务启动，对已在跑的无效；真要控速，用WAIT+ 低POWER组合，例如：ALTER DISKGROUP FRADG REBALANCE POWER 2 WAIT;
为什么改了参数还是慢？三个高频盲区
很多人调完 asm_power_limit 就等结果，却漏掉了关键上下文：
- 重平衡分三阶段：plan → redistribute → compact，前两阶段耗时占 90% 以上；
v$asm_operation的sofar/est_work只反映第二阶段，plan 阶段不计数也不报进度 - RAC 环境下所有节点共享同一套磁盘组 I/O，某个节点改了
asm_power_limit，其他节点仍按旧值调度 ARB 进程，需逐个确认 -
COMPATIBLE.ASM升级后，老磁盘组不会自动继承新范围——必须显式ALTER DISKGROUP ... SET ATTRIBUTE 'compatible.asm' = '19.0.0'才能解锁0–1024范围
最常被忽略的一点：重平衡速度的理论上限，取决于磁盘组里最小那块盘的吞吐能力，而不是你设的 POWER 值。再高的 POWER 也填不满机械盘的 I/O 瓶颈。
