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的奇怪案例

近期某客户一套环境出现异常,当进行alter diskgroup xxx modify power 0后;再次启动rebalance,发现无法启动rebalance,arb、rbal进程没有任何反应,现象大致如下:

 

当打开asm trace跟踪后,发现了一些蛛丝马迹:

alter system set events ‘15195 trace name context forever,level 7’;

 

从第一次的trace来看,oracle asm提示相关disk pst partner信息有问题;因此我们使用了level 0x39 进行了pst partner关系的重建。但是发现仍然无法解决问题,后面再报kfgpGet: insufficient space provided by caller. size 21, pcnt 20, KFPTNR_MAXTOT 20。

针对该问题,我在我们内部测试环境进行了相关模拟,通过频繁offline、drop disk然后add disk,在磁盘操作过程后,多次进行rebalance power的修改;大约测试了不下10次,最终遇到了一个未知的错误:

 

上述错误之前从未遇见过,可见Oracle 19c 版本中,对于ASM 的管理仍然存在一些不足之处;频繁的进行disk drop、add操作;在rebalance没有完成之前,是可能引发一些问题的,不过从测试来看,19c版本相比11.2.0.4版本,ASM 相关检测机制更加完善了,也更加健壮了一些。

再回到本次的案例。在一筹莫展之际,某天晚上,该用户环境其中一个存储节点磁盘被offline,通过online激活后,竟然发现磁盘组rebalance操作可以正常进行了。为此我进行了进一步跟踪分析,如下是此次磁盘offline涉及到的相关disk:

 

我们发现一共涉及到4个disk,分别是82/88/94/100 4个disk。从前面的trace 我们知道,之前无法进行rebalance的原因主要是卡在了disk 120上,且Oracle提示该disk pst的slot 已达到最大值,实际上通过kfed分析发现该结构最大就是20.

那么为什么巧合之际有4个盘被offline、online之后,整个diskgroup rebalance操作就恢复正常了呢?

最终我们分析发现此次offline操作的4个盘之一是88,其中该磁盘正好是120 disk的partner。我们认为offline 操作后,最终使oracle跳过了针对disk 120的一致性检查。

从这里看,我们之前给用户提供的解决方案也是符合的:

1、offline disk 120;然后online(offline、online过程不会除非rebalance,在disk repair time之内)

2、drop 120 disk force;然后手工执行rebalance。

 

这个案例相对比较有意思,特此简单记录一下。比较特殊的是该diskgroup 比较大,大概250TB,因为操作比较慎重。

Leave a Reply

You must be logged in to post a comment.