Exadata FAQ——为什么ASM rebalance hang在EST_MINUTES=0

原文链接: http://www.dbaleet.org/why_asm_rebanlance_hang_at_est_minutes_eq_zero/

最早故事大概发生在一年前,当时某个客户Exadata有几个盘坏了,需要更换。当时正好我在客户现场做一个变更,正好帮忙换一下硬盘,因为Exadata换盘的步骤比较繁琐,客户也是第一次遇到这样的事情,所以也格外谨慎。变更是在凌晨,此时业务量非常小,所以索性将ASM_POWER_LIMIT开足马力调整到11。期望rebalance能快点结束。还好一切顺利,中间并没有遇到什么差错。最后一部将ASM磁盘加回到asm diskgroup也很顺利,然后不停的在刷着select * from v$asm_opearation; /之类的。两小时后,眼看EST_MINUTES就马上接近于零了,换盘工作也即将结束。于是乎就去找客户闲聊,拉拉家常。半个小时过去了,我回到座位,熟练的敲了一下/,口里还念叨了一句:no row selected大大出乎我的意料的是竟然还有记录。越想越不对,10g的ASM也算换过不少次了,从来没出现像现在这样的。难道这个参数不准?下意识的去存储节点看了下iostat的结果,发现I/O量还是很大的。这个时候已经是凌晨3点了,不应该有这么大的访问量才对呀。我又简单的看了下db的负载一切正常,这就奇怪了。干脆一不做,二不休等吧。查询v$asm_operation得到的结果基本是这样的:

SQL>select * from v$asm_operation;

GROUP_NUMBER OPERA STAT      POWER     ACTUAL      SOFAR   EST_WORK   EST_RATE EST_MINUTES ERROR_CODE

------------ ----- ---- ---------- ---------- ---------- ---------- ---------- ----------- --------------------------------------------

           1 REBAL RUN          11         11       5518       5917       3250           0

一个小时过去了, 没变。

两个小时过去了,不见动静。

四个小时过去了,马上就天亮了。如果还不完成的话,那么就立即到营业时间了,眼看就快过了维护窗口了,如果不能完成可能就影响到业务了。我不停的刷着/, 期望rebalace能尽快结束,终于在四个半小时小时以后出现了久违的no row selected。当时我就想肯定是这个EST_MINUTES估算值不准导致的。因为10g时代已经习惯了v$session_longops不准了。但是令人十分费解的是加几个盘也用不了这么久吧?正常情况下两个小时就结束了,Exadata号称性能最强的数据库一体机,连普通的PC server都不如?

一个月以后,同样的事情有一次碰到,但是我不在客户现场了。这是国内某大型的金融客户。客户告诉我,他们加盘的动作是设定某个时间段进行,预估的时间是根据个EST_MINUTES算出来,然后多加一个小时,在10g时代,客户一直是这么做的。结果竟然2-3小时还没完,影响到业务了。这个时候,这个问题我已经知道是为什么了,但是我并没有说明具体的原因,只是告诉他这个估算出来的值不准,并且加盘减盘最好不要设定死固定的窗口, ASM_POWER_LIMIT不要虽然调整到最大值,设置为4就行了,这样不会影响业务。

时隔不久,竟然又有同事遇到了同样的问题,但是这次不是在exadata上,只是普通的11.2.0.2的数据。

实际上:EST_MINUTES 是按照以下公式计算的:

EST_MINUTES = (EST_WORK-SOFAR)/ EST_RATE

客户这个例子EST_MINUTES=(5917-5518)/3250=0.12m 约等于0, 证明rebalance已经“结束”。但为什么select * from v$asm_operation中还显示有记录呢,并且时间都是非常的长。

那这两者会有什么不同,这个时候,ASM正在做什么呢?我们猜测在EST_MINUTES=0, 并且select * from v$asm_operation的时候,ASM一定在后台进行某种秘密的活动。因为最终的rebalance是由ARB0完成的,所以我们想通过对ARB0进程在这两个阶段分别进行debug,然后对比其异同:

首先在EST_MINUTES不为0的时候,ARB0的堆栈如下:

kfk_reap_oss_async_io <-kfk_reap_ios_from_subsys<-kfk_reap_ios<-kfk_io1<-kfkRequest<-kfk_transitIO<-kffRelocateWait<-kffRelocate<-kfdaExecute <-kfgbRebalExecute<-kfgbDriver<-ksbabs<-kfgbRun<-ksbrdp<-opirip<-opidrv <-sou2o<-opimai_real<-ssthrdmain <-main

从上面的堆栈函数,我们可以猜测到此时ARB0进程一定是在做段的分配,并且等待段的分配的完成。

当EST_MINUTES=0, 但是v$asm_operation视图还有值的时候,再ARB0进行debug:得到的堆栈信息明显就有不一样了:

kfk_reap_oss_async_io<-kfk_reap_ios_from_subsys<-kfk_reap_ios<-kfk_io1
<-kfkRequest<-kfk_transitIO<-kffRelocateWait<-kffRelocate<-kfdaExecute<-kfdCompact<-kfdExecute<-kfgbRebalExecute<-kfgbDriver<-ksbabs<-kfgbRun<-ksbrdp<-opirip<-opidrv<-sou2o<-opimai_real<-ssthrdmain<-main

可以看到其中有个函数的名字叫做kfdCompact, 所以我们猜测这个神秘的阶段ARB0进程是在做compact这个动作。从这个compact来看,这个动作显然是11.2ASM的一个未公开的新特性,一个对数据进行重组和优化的阶段。后来发现这个动作并不是每次rebalance的时候都会发生。这个动作所做的事情实际上是把数据尽量挪到外圈加快访问速度。这个过程并不是必须的,可以通过以下隐含参数禁用:_DISABLE_REBALANCE_COMPACT=TRUE,值得注意的是这个神奇的参数在11.2.0.3以下版本最好不要禁用,原因在于: Bug 10022980 – DISK NOT EXPELLED WHEN COMPACT DISABLED, 这个bug在11.2.0.3修复。当然还有一种方式就是隐含参数_REBALANCE_COMPACT设置为false。

我的建议是,如果对于lun, 数据本身已经打散,ASM根本不知道磁盘的最外圈在什么地方,所以这种情况下,应该将这个compact这个过程禁用,以免耽误很长的时候,而结果却适得其反。如果ASM盘是裸盘,则不要关闭这个特性。在Exadata上,同样不要禁用这个特性。当然同时,请不要将轻易将ASM_POWER_LIMIT设置为最大值,然后进行rebalance, 一种思路是将ASM_POWER_LIMIT调整到4左右,然后添加/删除/替换磁盘,让其在后台进行,然后写一个脚本每隔几分钟查询一次v$asm_operation,如果返回空行,则表示rebalance已经成功,然后想dba team发送邮件或者短信通知。

最后需要补充一句的事情是:这个问题已经被oracle当作一个bug处理,Bug 9311185: EST_MINUTES IN V$ASM_OPERATION MAY SHOW ZERO FOR EXTENDED PERIODS, 也就是没有办法监控到compact的完成度,这个由于已有的代码问题,在11.2中几乎无法修复。12c中确认已经修复。

以上

 

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号