重平衡慢主因是底层i/o故障或参数未生效，非asm配置问题；需查smartctl三项指标、/var/log/messages错误、dd写入延迟，确认dropping盘状态及cssd心跳，并用alter diskgroup rebalance power n强制指定本次操作功率。
重平衡慢不是配置错了，而是你没看清它卡在哪一层——90% 的 case 根本不是 asm 本身慢，是底层 i/o 在“装死”或参数在“假跑”。
查 v$asm_operation 显示 EXECUTING 但 est_minutes 不动
这不是 rebalance 慢，是 ASM 卡在底层读写失败上。常见表现：sofar 几乎不涨、power 值稳定但无实际迁移、repair_timer = 0 且磁盘 state = DROPPING。
- 立刻在所有 RAC 节点执行
smartctl -a /dev/sdX，盯紧Reallocated_Sector_Ct、Current_Pending_Sector、UDMA_CRC_Error_Count——任一非零，该盘就是定时炸弹 - grep
"I/O error\|aborted command\|resetting link"/var/log/messages，时间戳必须和 rebalance 启动时间对齐 - 用
dd if=/dev/zero of=/dev/sdX bs=1M count=1024 oflag=direct测延迟：单次 >500ms 或报Input/output error，直接标记为故障盘 - 别信
asmcmd lsdsk——它只认路径通不通，不认扇区能不能写
POWER 设成 11 但 I/O 没涨，rebalance 还是慢
说明你改的是全局 asm_power_limit，但当前 rebalance 操作早已按旧值启动；或者 RAC 中某节点 CSSD 心跳异常，导致 ARB 进程无法协同。
- 确认当前操作是否真用了新 POWER：
SELECT inst_id, operation, state, power, sofar, est_work FROM gv$asm_operation—— 若power列没变，说明 ALTER SYSTEM 生效了，但本次 rebalance 没继承 - 强制指定 POWER 才有效：
ALTER DISKGROUP dg1 REBALANCE POWER 7（注意：不是改参数，是改这次操作） - 检查集群健康：
SELECT * FROM gv$css_history WHERE status != 'SUCCESS'，INTERMEDIATE 或 FAILED 记录意味着节点间同步已断 - 全闪存阵列可设到 6–8；混闪或机械盘务必 ≤4，并用
iostat -xm 1实时盯%util和await，>95% 或 >20ms 就得降 POWER
新加磁盘后 rebalance 卡住，v$asm_operation 显示 WAITING
WAITING 不代表空闲，而是 ASM 在等前置条件满足——最常见是磁盘组里还有别的操作没结束，或某块盘处于 PROVISIONED/UNKNOWN 状态没真正上线。
- 先清场：
SELECT * FROM v$asm_operation必须返回空结果，否则 DROP/ADD/REBALANCE 都会被阻塞 - 查磁盘真实状态：
SELECT name, state, header_status, mode_status FROM v$asm_disk WHERE group_number = (SELECT group_number FROM v$asm_diskgroup WHERE name = 'DG_NAME')—— 若header_status是PROVISIONED，说明盘已识别但未完成 ASM 元数据初始化，需手工ALTER DISKGROUP ... ADD DISK ...再试 - EXTERNAL 冗余磁盘组掉盘即丢数据，别指望 rebalance 救命；NORMAL/ HIGH 冗余下，若
repair_timer > 0，说明还在等盘自己回来，别急着 DROP - 加盘后不要立刻 rebalance：先
ALTER DISKGROUP ... ADD DISK ...，等v$asm_disk.header_status = MEMBER稳定 2 分钟再发 REBALANCE
explain work for 返回 est_work 很大，但实际跑起来更慢
v$asm_estimate.est_work 只算 AU 数量，不反映 I/O 延迟、AU 碎片度、FailGroup 物理隔离性 —— 它是理论值，不是工期表。
- est_work 高 ≠ 一定慢：如果所有磁盘性能一致、FailGroup 分布合理、无坏道，POWER=5 可能比 POWER=1 快 8 倍
- est_work 低却跑得慢：大概率是某块盘响应异常，导致 ARB 进程反复 timeout 重试，实际有效吞吐极低
- 别依赖默认 AU 大小：OLTP 系统用 1MB AU + 细条带；DSS 类负载若 AU 设成 4MB，但其中一块盘是旧 SAS 盘，整个 rebalance 会被拖垮（木桶效应）
- 重建磁盘组前，用
ls -l /dev/disk/by-path/确认每块盘物理路径是否真正分散 —— 同一 HBA 卡下的多块盘，再细的条带也白搭
真正耗时的从来不是算法，是那块没人盯着的、smartctl 里藏着 Current_Pending_Sector=1 却还在 state=ONLINE 的磁盘。
