ASM磁盘组添加磁盘后不会立刻REBALANCE，因ADD DISK仅更新元数据，需手动执行ALTER DISKGROUP…REBALANCE或触发其他重分布操作；删除磁盘卡在WAITING时应检查AU迁移状态并调高POWER值推进。
ASM磁盘组添加磁盘后为什么没立刻开始REBALANCE
因为oracle默认不自动触发，必须显式发起或等后续操作触发。添加磁盘本身只是元数据变更，alter diskgroup ... add disk 执行完后，磁盘处于“online”但未参与数据重分布的状态。
- 手动启动：执行
ALTER DISKGROUP <dg_name> REBALANCE POWER <n></n></dg_name>（<n></n>是 0–11 的整数，0 表示暂停，1 最慢，11 最激进） - 自动触发条件：只有当磁盘组中已有
REBALANCE正在运行，或你执行了涉及数据移动的操作（如删除磁盘、调整 AU 大小），才会顺带触发；单纯ADD DISK不会 - 检查状态：查
V$ASM_OPERATION，STATE = 'RUNNING'且OPERATION = 'REBAL'才算真在跑
删除磁盘时REBALANCE卡在WAITING状态怎么破
常见于目标磁盘上仍有分配单元（AU）未迁移完，但 ASM 认为它“可删”，于是挂起等待——本质是依赖内部协调机制，而该机制有时被阻塞。
- 先确认是否真卡住：查
V$ASM_DISK中该磁盘的STATE应为DROPPING，再看V$ASM_OPERATION的POWER和EST_MINUTES是否长期不变 - 强制推进：执行
ALTER DISKGROUP <dg_name> REBALANCE POWER 11</dg_name>（别用 0，那是停） - 极端情况需中断再重试：先
ALTER DISKGROUP <dg_name> STOP REBALANCE</dg_name>，等V$ASM_OPERATION清空后，再START REBALANCE - 注意：若磁盘物理已离线（如路径失效），
DROPPING状态可能永远无法完成，得先用FORCE选项或从 OS 层恢复设备可见性
REBALANCE POWER值设太高反而拖慢整体IO怎么办
Power 值不是越大越好，它控制的是并发程度和资源抢占强度，对共享存储（尤其是SAN或NVMe共享池）影响显著。
-
POWER 11会让 ASM 尝试占满所有可用 IO 资源，可能挤占数据库前台读写，导致 SQL 响应变慢甚至超时 - 生产环境建议从
POWER 3~5起步，观察V$ASM_DISK_IOSTAT中的READS/WRITES和延迟变化 - 如果磁盘组底层是高延迟设备（如旧 SATA 盘组成的 LUN），
POWER > 3往往引发大量 IO 队列堆积，IO_WAIT上升比数据迁移还快 - 动态调速可行：REBALANCE 运行中可随时执行
ALTER DISKGROUP <dg_name> REBALANCE POWER <new_n></new_n></dg_name>调整，无需中断
ASM磁盘组REBALANCE期间数据库能正常访问吗
能，但性能敏感型负载会感知到抖动，尤其当磁盘组承载 SYSTEM、SYSAUX 或频繁写的表空间时。
- REBALANCE 本身不锁表、不阻塞 DML，但会争抢底层磁盘 IO 和内存（ASM cache）、CPU（校验计算）资源
- 典型症状：SQL 执行计划突变（因 buffer cache 命中率下降）、归档日志写入延迟升高、RMAN 备份速度变慢
- 关键规避点：避免在业务高峰执行大范围 REBALANCE；不要在同一个磁盘组里同时做
ADD DISK和DROP DISK，这会触发两轮重平衡，叠加压力 - 监控锚点：盯紧
V$ASM_OPERATION的SOFRATE（每秒迁移 MB 数）和V$ASM_DISK_IOSTAT的AVG_READ_TIME，超过平时 2 倍就该干预
REBALANCE 看似自动，实则每一步都依赖 ASM 对磁盘状态、IO 能力和数据分布的实时估算——这些估算没有外部反馈闭环，一旦底层存储响应异常或元数据滞后，就容易陷入“以为在动，其实卡死”的状态。最常被忽略的是：删盘前没确认磁盘是否真被完全清空，或者加盘后忘了手动启 rebalance。
