Oracle ASM Rebalance特性浅解

ASM动态重新平衡特性

在ASM环境中，有一个重要的特性叫做动态重新平衡（Rebalancing），即当ASM需要增加磁盘

空间时，可将新的磁盘设备添加到磁盘组，ASM磁盘组会按照一定比例将数据从一个或多个已有的磁盘移动到新的磁盘，从而维持所有磁盘之间整体的I/O平衡。

这种特性也提供了将整个数据库从一组较慢的磁盘迁移到一组较快磁盘的迁移方法，而且整个

过程数据库能保持联机状态。当重新平衡操作完成后，我们可以剔除较慢的磁盘组，保留较快磁盘的磁盘组，从而完成联机状态下的数据迁移。

动态重新平衡触发条件

Rebalancing触发条件：当ASM需要改变磁盘的配置时，比如往ASM当前磁盘组中添加新的磁盘

成员（alter diskgroup data add disk '/dev/raw/raw7';），删除故障组的磁盘（alter diskgroup data drop disk 'name';），添加新的磁盘组或者删除旧的磁盘组等等，只要当数据库联机并且用户正在使用该数据库时，都将触发ASM进行动态的重新平衡。

当然也可以通过更改ASM初始参数ASM_POWER_LIMIT的值或使用ALTER DISKGROUP REBALANCE POWER ，可控制磁盘重平衡的速度及对运行数据库I/O的影响。11.2.0.2版本以上，ASM_POWER_LIMIT和POWER的取值范围是0-1024，数值越大并发越高，重平衡速度也越快，后台I/O消耗越大。

使用ASM_POWER_LiMIT 调整rebalance 并发，asm_power_limit 默认值为1，若设置0，则为禁止rebalancing。

使用ALTER DISKGROUP REBALANCE POWER改变磁盘动态平衡时间，power值越大，迁移速度越快，I/O消耗也越大。

重平衡时间预估及后台追踪

经常有客户会问：“咱使用ASM磁盘迁移数据多长时间完成？”其实在ASM环境中，ASM会根据

当前数据库磁盘组大小、个数、性能、数据库整体I/O负载及asm_power_limit等综合因素，给出的一个完成的预估时间，我们可以通过GV$ASM_OPERATION.EST_MINUTES这个字段查到。但是如果我们想要更精确的知道现在rebalance到什么阶段，我们就需要了解一下关于重平衡的三个阶段。

第一阶段：rebalance plan，ASM会计算出重平衡的计划。计划取决于很多因素，例如磁盘组大

小、磁盘组中的文件个数、磁盘的partnership是否需要调整等等。这个过程时间不会太长，一般不会超过几分钟。

第二阶段：extent relocating，区迁移是真正干活的阶段，这个阶段，ASM的区会在磁盘组中

的磁盘间移动，这个过程会花费大部分的时间。这个过程中，ASM会记录区的移动数量，以及实际的I/O性能，从而估算该过程需要花费的时间（GV$ASM_OPERATION.EST_MINUTES记录估算出的时间)。不过要注意的是，这只是估算的时间，真正的花费时间还取决于整体负载（特别是磁盘相关的负载）。

图1

图1中，EST_MINUTES的预估值第一次显示2分钟，再次刷新显示1分钟。有些时候EST_MINUTES的值可能并不能给你太多的证据，我们还可以看到SOFAR（截止目前移动的UA数）的值一直在增加，这也是一个很好的一个观察动态平衡指标。

第三阶段是磁盘的compacting阶段（ASM 11.1.0.7版本及以上支持），这个过程是将磁盘上存

的数据尽可能的移动到磁盘的外圈磁道上去（机械盘的外圈速度更快），以提供更高的性能。实际上，你了解了第二个阶段extent relocation什么时候完成，一旦它完成了，整个磁盘组的冗余就已经完成了。

图2

图2中，est_minutes显示为0,并不能代表rebalance完全结束，我们还可以通过ARB0进程的trc追踪文件,当前正在对哪一个ASM文件的extent的在进行重分配tail -200f /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_8568.trc 来观察或者还可以通过ASM的alert日志中也可以显示磁盘的操作，图3为 +ASM1_arb0_8568.trc