ASM磁盘空间假装耗尽，ORA-15041: diskgroup space exhausted

一个DATAGUARD，当主库RESIZE扩大一个数据文件后，DG上面却不能应用这个RESIZE的操作，导致MPR进程停掉，报错如下：
ORA-01237: cannot extend datafile 123
ORA-01110: data file 516: '+DG01/dg/datafile/aa.276.689185035'
ORA-17505: ksfdrsz:1 Failed to resize file to size 3053300 blocks
ORA-15041: diskgroup space exhausted
本来想这个错误太明显了，无非是因为DG上面得ASM组没有空闲空间了，导致数据文件不能扩展。于是登陆ASM实例，查询空闲空间，结果如下：
SQL> select name,total_mb,free_mb from v$asm_diskgroup;

NAME TOTAL_MB FREE_MB
------------------------------ ---------- ----------
DG01 5209505 884073
DG02 1023994 988091
也就是说DG01命名还有将近900G的空间，却给我说空间不够了，这下抓瞎啦，见鬼的问题来了

第一反应就是这肯定是个BUG！登陆ML开始狂搜，结果发现碰到类似问题的人太多了，而且ASM类似的BUG也是一大堆，没眉目了。其中一个最引起注意的是这么一个地方（ML:389877.1），大概意思就是说：
一般我们都是去V$ASM_DISKGROUP或者V$ASM_DISK中来查看ASM组总共有多少空间，还剩余了多少空间，大多数情况下呢，这个数字是准确的，但是有时候呢，ORACLE会忽悠你！ASM中记录这些空间使用信息的地方有两个，上面只是其中一个地方（叫disk directory），还有另外一个地方(allocation tables)。那么当你在RESIZE的时候呢，如果这个RESIZE失败了，那么DIRECTORY中的数字是不会更新的，这是对的，因为本来空间就没分配成功嘛，但是，ALLOCATION TABLE是会更新的，所以就导致了你从V$ASM_DISKGROUP中看到有很多空间信息，但是干着急就是没法用。那么怎么确认是否有这种问题存在呢？

select group_number,file_number,bytes,space from v$asm_file，在这个SQL的返回结果中，BYTES是数据文件实际的大小，而SPACE是数据文件占用的ASM空间的大小，而ASM磁盘有三种冗余方式，分别是EXTERNAL/NORMAL/HIGH，这三种情况下，SPACE分别应该是BYTES的1倍（也就是基本相等）、两倍和三倍。如果某些数据文件不符合上面这个对应关系，那就应该是你撞上这个问题了。可是查下来这个问题在我这里不存在，SPACE确实比BYTES大，但都只是大了一点点。（对于上面这种情况，ML上面的做法是先把这个文件OFFLINE，然后备份，然后删除，然后再RESTORE回来，然后再RECOVER，然后再ONLINE，这样就OK了）

后来无头苍蝇一样乱撞吧，挨个看看v$asm开头的视图，结果看到v$asm_disk_stats的时候发现了问题。
select path,total_mb,free_mb from v$asm_disk_stat;
执行这个查询的时候，发现大多数些卷FREE_MB为0了，而有一个卷却有将近900G空闲空间。后来想起来了，当初RMAN复制这个库的时候，因为库正在恢复的时候发现空间很紧张，就加了1T空间上去，然后POWER为5开始REBALANCE，后来发现RMAN的复制很慢，就把REBALANCE POWER改成0了，复制完把这茬给忘了，结果一直都没有REBALANCE（本来想着系统自己的REBALANCE POWER设置为1，它自己会慢慢的REBALANCE的），从而导致了今天的问题。

最终，开始POWER 11的REBALANCE，等每个卷都有不少空间空间的时候开始恢复，报错的地方已经能够过去了，剩下的就是慢慢等着恢复和REBALANCE就是了