遇到ASM的兩個BUG

最近在ASM上遇到幾個BUG，這裡簡單記錄下來。

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production

TNS for Solaris: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production

BUG 1：V$ASM_DISK和V$ASM_DISKGROUP顯示的剩餘空間不一致。
--database 例項
SQL> select total_mb,free_mb from v$asm_diskgroup;

TOTAL_MB FREE_MB
---------- ----------
307201 100536

SQL> select total_mb,free_mb from v$asm_disk;

TOTAL_MB FREE_MB
---------- ----------
102399 0
204802 0

這個可能oracle認為不算bug，因為在asm例項查是沒有問題的:
--ASM 例項
SQL> select free_mb,total_mb from v$asm_diskgroup;

FREE_MB TOTAL_MB
---------- ----------
98419 307201

SQL> select free_mb,total_mb from v$asm_disk;

FREE_MB TOTAL_MB
---------- ----------
0 500
0 500
16905 102399
81514 204802

在這裡的查詢結果看，還是正確的。
oracle文件沒有明確說明在database例項查詢時結果是不一致的（很多asm檢視在資料庫例項是沒有結果的，但文件都有說明），因此這裡也把它歸結為BUG吧。

BUG 2:ORA-15041: diskgroup space exhausted

完整的報警資訊如下：
Fri Oct 19 23:52:00 2007
Errors in file /oracle/app/admin/pre/bdump/prerac1_arc1_3549.trc:
ORA-19504: failed to create file "+DATA/archivelog/1_84_634432026.dbf"
ORA-17502: ksfdcre:4 Failed to create file +DATA/archivelog/1_84_634432026.dbf
ORA-15041: diskgroup space exhausted

嘗試手工歸檔失敗：
SQL> alter system archive log current;

alter system archive log current

ORA-16038: log 4 sequence# 84 cannot be archived
ORA-19504: failed to create file ""
ORA-00312: online log 4 thread 1: '+DATA/onlinelog/redo1_4_1.log'
ORA-00312: online log 4 thread 1: '+DATA/onlinelog/redo1_4_2.log'

這個問題之前遇到過，但沒有深究，當時刪除了一些歸檔釋放部分空間後，重啟例項就在表面上解決問題了，但今天發現問題沒有這麼簡單，因為從查詢結果看，空間還是足夠的：
這是asmcmd的檢視結果：
ASMCMD> lsdg
State Type Rebal Unbal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Name
MOUNTED EXTERN N N 512 4096 1048576 307201 100552 0 100552 0 DATA/

這是從檢視檢視的結果：
SQL> select total_mb,free_mb from v$asm_diskgroup;

TOTAL_MB FREE_MB
---------- ----------
307201 100536

從兩個查詢結果看都有100多G的空間空間，但是在歸檔500多M的日誌的時候仍然會包空間不足。
上metalink查了一下，發現這又是一個bug：DISKGROUP組內的disk使用不能自動均衡，導致其中一個磁碟空間爆滿，不能建立新檔案。
原因是ASM會嘗試把資料分佈在所有的磁碟中，如果其中一個disk滿了，即使其實的磁碟有足夠的空閒空間也不能建立新檔案了。
觸發這個BUG的條件有兩個：
1、diskgroup只有2塊磁碟
2、兩個磁碟的尺寸不一致。
很不幸，我的環境完全滿足這兩個條件。這個bug在11g會被修正，目前對於這個問題，oracle提供了一個解決方法：REBALANCE磁碟組。
要注意，重平衡磁碟組要把ASM磁碟組的資料重新分配空間，這個工作非常耗費資源，在正式環境不要輕易執行這個命令：

SQL> ALTER DISKGROUP DATA REBALANCE POWER 11;

Diskgroup altered.

其中11可以替換為1-11之間的任意整數，數值越大，重組越徹底，耗費時間就越長。

發出這個命令後，在ASM例項查詢v$asm_operation來看ASM重組的進度：
SQL> select * from v$asm_operation;

GROUP_NUMBER OPERATION STATE POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES
------------ ---------- -------- ---------- ---------- ---------- ---------- ---------- -----------
1 REBAL RUN 11 11 4395 36847 771 42

SQL> /

GROUP_NUMBER OPERATION STATE POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES
------------ ---------- -------- ---------- ---------- ---------- ---------- ---------- -----------
1 REBAL RUN 11 11 8132 47805 790 50

REBAL是REBALANCE的所寫。

再檢視V$ASM_DISK的情況：
SQL> select free_mb,total_mb from v$asm_disk;

FREE_MB TOTAL_MB
---------- ----------
0 500
0 500
16905 102399
81514 204802

隔一段時間後再次查詢：

SQL> /

FREE_MB TOTAL_MB
---------- ----------
0 500
0 500
17308 102399
81111 204802

可見，ASM磁碟組中的磁碟的使用率正在變化。

此時在database例項中嘗試歸檔：
SQL> alter system archive log current;

System altered

可以成功歸檔。這個命令執行起來可能有點慢，因為ASM資料重組程式與歸檔程式在空間使用上衝突，ASM重組程式會阻塞歸檔程式，直到歸檔需要的空間重組完成。

至此，這個bug得到暫時解決。