love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

asm rebalance 原理

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

本文链接地址: asm rebalance 原理

上周6,某客户进行存储扩容(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操作.

那么,asm diskgroup的rebalance操作,到底需要做什么呢 ?或者说包含了哪些步骤 ?

不同的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.

2 Responses to “asm rebalance 原理”

  1. asm rebalance 原理 - 数据库 - 开发者 Says:

    […] 详见原文博客链接地址:asm rebalance 原理 本文链接: asm rebalance 原理 版权所有: 非特殊声明均为本站原创文章,转载请注明出处:开发者 订阅更新: 您可以通过RSS订阅我们的内容更新 […]

  2. d Says:

Leave a Reply

You must be logged in to post a comment.