oracle 12c rac中asm重平衡慢主因是默认asm_power_limit=1保业务稳定，并非性能故障；需查gv$asm_operation确认是否真执行、卡在plan/redistribute/compact哪阶段，结合iostat盯%util与await，rac下须逐节点验证asm_power_limit及cssd心跳。
oracle 12c rac 中 asm 重平衡慢，不是 asm 坏了，而是默认 asm_power_limit=1 在“守门”——它优先保业务不抖，不是跑不动。
怎么确认当前重平衡到底卡在哪一步
别只查 v$asm_operation 有没有记录。先看它是否真在跑：
-
SELECT inst_id, operation, state, power, sofar, est_work FROM gv$asm_operation;—— 没结果？说明根本没触发重平衡（比如磁盘刚加完，但 ASM 还没自动启动） - 有记录但
power列是 0？不是参数没生效，而是有人执行过ALTER DISKGROUP dg1 REBALANCE POWER 0主动挂起了它 -
state = 'EXECUTING'但sofar长期不动？大概率是底层存储响应延迟高：机械盘await > 50ms，或全闪阵列%util > 95%
改 asm_power_limit 前必须盯住两个硬限制
这个参数不是设得越高越快，实际生效受 ASM 兼容性与 RAC 实例状态双重约束：
- 查磁盘组实际兼容版本：
SELECT name, compatibility, database_compatibility FROM v$asm_diskgroup;—— 如果compatibility ，哪怕你设成 11，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 dg1 REBALANCE POWER N才能干预正在运行的任务
为什么调了参数还是慢？三个高频盲区
很多人改完 asm_power_limit 就等结果，却漏掉了关键上下文：
- 重平衡分三阶段：
plan → redistribute → compact，前两阶段耗时占 90% 以上；v$asm_operation的sofar/est_work只反映第二阶段，plan阶段不计数也不报进度 - RAC 环境下所有节点共享同一套磁盘组 I/O，某个节点改了
asm_power_limit，其他节点仍按旧值调度 ARB 进程，需逐个确认 -
POWER设成 11 但 I/O 没涨？说明你改的是全局参数，但当前 rebalance 操作早已按旧值启动；或者某节点 CSSD 心跳异常，导致 ARB 进程无法协同
最常被忽略的一点：重平衡不是“越快越好”，而是“快到不拖垮业务”。全闪存可试 POWER 6–8，混闪或 SAS 盘务必 ≤4，并用 iostat -xm 1 实时盯 %util 和 await——一旦 %util > 90% 或 await > 20ms，就得立刻降 POWER，否则 SQL 响应会集体变慢。
