oracle rac中不存在基于策略的asm磁盘组热点均衡机制，asm不采集i/o指标动态迁移数据；其rebalance仅响应加盘、删盘等显式操作，所有“均衡”均源于初始设计（如failgroup、au_size、冗余类型）的静态条带化与镜像分布。
oracle rac中不存在“基于策略的asm磁盘组热点均衡”这种运行时可配置的策略机制——asm本身不提供按访问热度动态迁移盘区（extent）或文件的智能负载调度能力。所谓“热点均衡”，本质是通过初始设计规避热点，而非事后调控。
为什么asmcmd和ASMCMD里没有balance_hotspots或类似命令
ASM的再平衡（rebalance）只响应显式触发的操作：加盘、删盘、调power_limit，或故障组成员变更。它不采集I/O延迟、排队长度或单盘吞吐率等指标，也不据此主动迁移数据。所有“均衡”都是静态条带化+冗余分布的副产品，不是运行时策略驱动的结果。
- 你看到的
rebalance进度，只是把新增/移除盘导致的空间分布失衡，按AU粒度重新摊开，并非感知到某块盘变热了才去动它 -
v$asm_disk_iostat能查历史IO统计，但ASM不基于它做任何自动动作；DBA需人工比对reads/writes/read_time后决定是否重建磁盘组 - 试图用
alter diskgroup ... rebalance power 11强行加速，反而可能因高并发IO加剧争用，尤其在OLTP场景下
CREATE DISKGROUP时必须硬编码的3个防热点参数
真正影响IO是否倾斜的，是建组那一刻就定死的物理与逻辑结构。后续无法在线修改，只能重建：
-
FAILGROUP必须对应真实物理隔离单元：同一RAID卡、同一HBA通道、同一SAN阵列端口下的盘，绝不能混入同一FAILGROUP——否则条带再细也跑在同一硬件路径上 -
au_size要匹配业务特征：1M适合OLTP（小IO随机读写），4M适合DSS（大顺序读），设错会导致元数据锁争用或单AU跨多盘IO放大 - 冗余类型决定镜像落盘逻辑：
NORMAL REDUNDANCY要求至少2个FAILGROUP，主盘区和镜像盘区强制分置；若只建1个FAILGROUP，ASM会静默降级为外部冗余，失去镜像保护且IO全压在一组盘上
发现热点后唯一有效的“均衡”操作是重建磁盘组
当select path, reads, writes, read_time from v$asm_disk显示某盘read_time持续高于均值2倍以上，且path指向同一物理控制器时，说明初始设计已失效。此时：
- 先用
asmcmd ls -l确认当前磁盘组内各盘的FAILGROUP归属，再用ls -l /dev/disk/by-path/核对OS层实际物理路径是否真的分散 - 导出关键数据（如OCR/Voting Disk若在该组，必须先
ocrconfig -export） - 执行
DROP DISKGROUP ... INCLUDING CONTENTS（确保所有节点已卸载） - 用明确指定
FAILGROUP和au_size的CREATE DISKGROUP重建，例如：CREATE DISKGROUP dg_data NORMAL REDUNDANCY<br> FAILGROUP fg_a DISK '/dev/oracleasm/disks/DISK01' NAME disk01,<br> '/dev/oracleasm/disks/DISK02' NAME disk02<br> FAILGROUP fg_b DISK '/dev/oracleasm/disks/DISK03' NAME disk03,<br> '/dev/oracleasm/disks/DISK04' NAME disk04<br>ATTRIBUTE 'compatible.asm'='19.0.0.0', 'au_size'='1M';
最常被忽略的一点：FailGroup的物理边界必须由DBA亲手验证，不能依赖盘名顺序或ASM自动分组。一块盘挂错HBA口，整个磁盘组的“均衡”就只是幻觉。
