故障描述：
多节点oracle RAC11204环境下，分布式存储硬件检修后需要online磁盘，执行alter diskgroup ocr online disk OCR_0000，online命令hang，长时间没有反应，检查asm日志无报错信息。查询mos可能遭遇了bug ID:1232398.5，ASM在集群范围有锁。
查询ASM集群范围锁信息如下：
SQL> select sql_text from v$sql wheresql_id='cx9y8a6kn1g5v';
SQL_TEXT
----------------------------
alter diskgroup ocr online disk OCR_0000
可以看到1648 session 正是我们online命令，等待KSV master wait事件和bug描述一致。
另外发现1709 session 等待DFS lock 被3号节点2319 session阻塞。
检查3号节点的2319 session，发现被1号节点的977 session阻塞，同样等待DFS LOCK。
2319 session 在做什么呢？
2319 在执行asm磁盘 rebalance 操作，检索asm日志发现该rebalance操作是下午执行
alter diskgroup ocr rebalance power 8 命令触发的。
日志信息类似如下：
NOTE: ASM did background COD recovery forgroup 4/0xaac86b7a (OCR)
NOTE: starting rebalance of group4/0xaac86b7a (OCR) at power 8
Starting background process ARB0
从这里也可以明白上面这个命令会触发rebalance操作，正确的做法应该是修改power 参数。
那么这个 rebalance 为何如此长时间没有平衡结束呢？而且也没有实际发生平衡操作。从上面的分析其实已经看出来了，因为1号节点977 session 阻塞了该rebalance 操作。继续分析1号节点的977 session：
977 是检查点进程。
一般遇到检查点阻塞问题，首先考虑刷新内存，该case刷新内存后问题依旧。
从上面的bug 信息中 oracle的建议是重启asm实例。为了最小范围影响业务，决定重启最终的阻塞者1号节点的asm实例。经过和客户商定最终重启了1号节点asm实例。再次观察asm集群等等发现，rebalance 成功执行，再次执行online 操作也成功。
问题还没有结束，那么从这个bug的描述可以看到该bug 在11204上已经修复了，那么为什么客户的环境遇到了该问题呢？继续检查发现下面信息：
原来客户的数据库兼容性设置太低。为了彻底修复该问题建议客户修改数据库兼容性参数为11.2.0.4.0
结束语：ASM 锁和其他锁的原理是相同的，但是一旦遇到可能会造成非常严重的后果。比如可能会导致整个集群io全部阻塞，集群宕机。本次提到的case中asm锁算是一个轻量级的锁。从问题的处理过程可以看到asm锁和其他锁的处理方式是一样的，都是找到最终的阻塞者解除锁即可。
