近期某客户一套环境出现异常，当进行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，因为操作比较慎重。