More about _asm_repairquantum

根据我们之前的更新我们能看到，这个问题的顺序如下，并且有如下的建议。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正常.=

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

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

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