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的空間，卻給我說空間不夠了，這下抓瞎啦，見鬼的問題來了

[@more@]

第一反應就是這肯定是個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就是了