深入内核：Asm Rebalance 原理SHAPE \* MERGEFORMAT

编辑手记：ASM Rebalance 的过程具体发生了什么操作呢，在不同版本间有什么样的区别，如何才能加快 Rebalance 的速度呢，本文将会解答你的困惑

我们先看一个例子

某客户进行存储扩容(11gR2 rac asm),扩容完成之后,我们需要将新划的lun加到现有的 asm diskgroup 中.整个扩容过程比较顺利,唯一让人比较郁闷的是在将一个 lun 加到 diskgroup时,时间太长。这个lun大小也就300gb,整个数据库数据也就不到100gb,add disk

rebalance需要花了3.5小时. 如下是操作节点的 alert log 信息 ：

可以看到，从03:10:25开始到06:41:25 才完成整个 rebalance 过程，也就是3小时31分钟.

到这里大家或许跟我一样，有一个疑问，那就是 oracle asm 的 rebalance 操作，具体包含了哪些细节？ 或者说 rebalance 操作需要做哪些事情 ？回答这个问题之前，首先我们需要明白，asm 在什么情况下进行 rebalance 操作.

实际上,rebalance 主要是在 diskgroup 中 disk member 发现变化时,比如 add/drop/resize

disk 操作.不同的 oracle 版本，其实rebalance 操作是有所差异的,在10g版本中,asm rebalance主要包含如下2个操作：

—planning

—extent relocatyion

然而在oracle 11.1版本中，引入了 asm fast rebalance 特性,大概是是说可以将 asm 实例启动到 Restricted mode 然后去完成 rebalance 操作。例如：

这一操作，在11.2中又有所变化，引入了一个 compact 操作，所谓 compact 操作，其实就是数据重组。 也就是说在11.2版本中,rebalance 操作应该包含如下几个步骤了：

1) planning

2) extent relocation

3) compacting

这里针对这几个步骤简单描述一下：

planning: 也就是说 oracle 会自己计算，绝对需要将那些 extent 进行 relocation 以及需要move 到什么地方去，应该也是用的 hash 算法.

extent

relocation:这个其实是根据前面 planning 的结果，将数据按照 extent 为单位进行move,移动到其他的 disk 上，均匀分布。我们称呼这个操作为 extent

relocation。一般来讲，这个操作是非常耗时的，也就是说整个 rebalance 操作中基本上时间大多的消耗在 relocation 这一步。当进行 extent

relocation 的时候，观察 rbal 的 log 会发现类似如下的信息：

在进行 extent

relocation 的阶段，是可以进行并行操作的，该操作是通过我们所熟知的一个参数 asm_power_limit

来进行控制。该参数在11.2.0.2以下版本中,其取值范围是0~11. 在11.2.0.2以及以上版本取值范围已经扩展为0~1024了.该参数控制rbal的 slave process 个数，换句话将，通常参数越大 rebalance 操作也就越快，当然这样也要看系统硬件配置.

另外有一点需要注意的是,rbal的slave process 的可以动态调整的，例如：

alter diskgroup

diskgroup_name rebalance power 5;需要注意的是，哪怕是你 alter diskgroup

add disk 命令已经发出了,也可以使用上面的方式来动态调整 rebalance power 值.

当rebalance power 值大于1后,oracle 会启动多个 rbal salve process 类似rba,rba1这样的命名.

这部分的消耗时间可以通过v$asm_operation.est_minutes

来进行估算，但是这个值不一定准确，受cpu,io等因素的影响。

compacting： 这个操作是11gR2引入的一个未公布的特性,其目的是在前面 extent

relocation完成之后,oracle 将 diskgroup 中都的每个 disk 中的数据进行重组。这里的重组其实是 disk 级别，不再是整个 diskgroup 级别. 其目的是将数据尽可能的挪到 disk 的外圈，这样可以加快访问，为什么可以加快访问？ 这样可以降低 disk 寻道时间.

关于该特性,11gR2版本中引入了1个参数来进行控制：_disable_rebalance_compact

我们可要通过动态调整该参数来关闭这个特性,当rebalance进行到这个步骤时,查询v$asm_operation.est_minutes会显示为0.这也就是为什么我们上次看到est_minutes为0了,rebalance 操作却还没有完成，还进行了1.5小时.

那么最后大家可能比较关心的是，如何加快asm rebalance的速度，大概有如下几种方法：

1) 调大 asm_power_limit 参数

2) 将参数

_disable_rebalance_compact 设置为 true,可动态调整

3) 设置 diskgroup 的 attributes 属性：_REBALANCE_COMPACT=false

4) 将参数

_asm_imbalance_tolerance 调的更低(11gR2默认为3%)

4) 调整参数 _disable_rebalance_space_check,关闭 compact 过程中的 space use 检查.

5) 调大 _asm_rebalance_plan_size 参数,该参数控制 maximum

rebalance work unit,通过调大该参数应该可以降低 extent

relocation 的次数,但是这个也受限于系统的 io 能力.

最后说明一下,对于生产环境而言，大多数情况下建议调大

asm_powner_limit 即可，其他几个隐含参数要慎重，可能碰到 bug.