More about _asm_repairquantum

More about _asm_repairquantum

参数_asm_repairquantum的值调大。让rebalance有足够的时间 结束。对于10g 的版本我们可以调高参数_asm_droptimeout 来拉长drop的间隔, 对于11g的版本,这个参数被重命名为_asm_repairquantum。

 

Comments

  1. 根据我们之前的更新我们能看到,这个问题的顺序如下,并且有如下的建议。1. asm 发现磁盘组DATA中的一块磁盘发生问题,并把这块磁盘offline,之后尝试删除这块磁盘,并开始rebalance。2. 接下来,ASM发现磁盘组DATA 中的其他很多磁盘都有问题,并把这些磁盘offline,之后删除。在删除磁盘的时候,ASM 要求rebalance一定要结束,并且会打断正在运行的rebalance过程。所以rebalance被 drop disk打断之后,会重新开始。但是过了大概3分钟(参数_asm_repairquantum的默认值)之后,asm会继续尝试删除 offline 掉的磁盘,并打断正在运行的rebalance过程,这就到时了rebalance 过程永远无法结束,drop disk 也无法成功。3. 对于这样的情况,我们能采用的解决方法就是,放大 asm 删除offline磁盘的间隔,也就是把参数_asm_repairquantum的值调大。让rebalance有足够的时间 结束。4. 另外,如果您的磁盘问题只是短暂出现的话,可以考虑使用oracle ASM 11g的新特性,“ASM Fast Mirror Resync” ,这样,asm 不会马上删除offline的磁盘。 当让,这需要您把compatible参数至少设置成11.15.最后, 我们在第2点中描述的现象和asm bug 5044180 是相符的,这个bug目前仍然在修复中。我们也会跟踪这个bug,如果有进展的话尽快通知您。1:修改隐含参数alter system set “_asm_repairquantum”=40000 scope=spfile;4 : 查v$asm_operation发现已有rebalance进行.执行alter diskgroup data rebalance power 10;经20多分钟后”_DROPPED*”没有存在于v$asm_disk视图里.6:已新增faligroup 方式执行add the disks back to diskgroup成功alter diskgroup data add failuregroup datafg3 disk “disk name list”8:alter diskgroup data rebalance power 11;经约2小时左右rebalance完成,9:重启RAC,库与asm正常.=

  2. 根据以上的输出,我们可以看到,当设置隐含参数_asm_repairquantum=40000,之后,磁盘组能够完成rebalance, 并且能够完成,因为asm 会在40000秒后才尝试删除offline掉的磁盘。 最后,磁盘可以被重新添加到磁盘组上。

  3. Customer has already set below paramerers. But still rebalance failed .asm_power_limit=11_asm_repairquantum=429496729_asm_imbalance_tolerance=0

  4. _asm_repairquantum quantum (in 3s) used to compute elapsed time for disk drop

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号