ASM磁碟故障診斷（一）

當時透過電話簡單瞭解了一下情況：Oracle 10204 RAC for Linux X86-64的環境，前一段時間作業系統出現了故障，導致一個節點重灌。重灌過程到了新增ASM例項的時候出現了錯誤。

一般來說，重灌過程最複雜的是CLUSTER的清除和新增，如果CLUSTER已經新增成功，那麼剩下的就是資料庫級的操作，相對來說會簡單得多。根據上面的資訊初步判斷，問題可能發生在幾點，新節點的ORACLE_HOME的版本和舊節點不一致，或者10204補丁沒有在CLUSTER上安裝，或者是在新節點上沒有給oracle使用者授權，還有可能就是共享儲存在新節點上掛載存在問題。

到了現場後才發現，問題和我的判斷大相徑庭，資料庫的版本，許可權等都不存在問題，事實上，新節點上的ASM例項已經啟動，且兩個磁碟組中的一個已經MOUNT，但另外一個磁碟組無法MOUNT：

SQL> alter diskgroup datag1 mount;
alter diskgroup datag1 mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATAG1"

ORA-15032只是一個描述性錯誤，而關鍵的ORA-15063錯誤比較少見。

由於另外一個節點從RAC環境出現故障後一直沒有停機，因此可以從這個節點的ASM例項上檢查磁碟組和磁碟的狀態：

SQL> select group_number, name, state, total_mb, free_mb from v$asm_diskgroup;

GROUP_NUMBER NAME          STATE                    TOTAL_MB    FREE_MB
------------ ------------------------------------ ---------- ----------
           1 DATAG1        MOUNTED                    512000     217396
           2 DATAG2        MOUNTED                   1024000     347457

SQL> select group_number, disk_number, mount_status, header_status, name, path from v$asm_disk where group_number = 1;

GROUP_NUMBER DISK_NUMBER MOUNT_STATUS HEADER_STATUS  NAME        PATH
------------ ----------- ------------ -------------- ----------- -------------
           1           0 CACHED       PROVISIONED    DATAG1_0000 /dev/raw/raw4
           1           1 CACHED       MEMBER         DATAG1_0001 /dev/raw/raw5

SQL> select instance_number, instance_name from v$instance;

INSTANCE_NUMBER INSTANCE_NAME
--------------- --------------------------------
              2 +ASM2

可以看到，磁碟組DATAG1中的磁碟DATAG1_0000的檔案頭狀態不正確。從新新增的例項1上檢查ASM磁碟資訊：

SQL> select group_number, name, state, total_mb, free_mb from v$asm_diskgroup;

GROUP_NUMBER NAME          STATE                    TOTAL_MB    FREE_MB
------------ ------------------------------------ ---------- ----------
           1 DATAG1        DISMOUNTED                      0          0
           2 DATAG2        MOUNTED                   1024000     347457

SQL> select group_number, disk_number, mount_status, header_status, name, path from v$asm_disk;

GROUP_NUMBER DISK_NUMBER MOUNT_STATUS HEADER_STATUS  NAME        PATH
------------ ----------- ------------ -------------- ----------- --------------
           0           0 CLOSED       FOREIGN                    /dev/raw/raw1
           0           1 CLOSED       FOREIGN                    /dev/raw/raw2
           0           2 CLOSED       FOREIGN                    /dev/raw/raw8
           0           3 CLOSED       FOREIGN                    /dev/raw/raw10
           0           4 CLOSED       FOREIGN                    /dev/raw/raw9
           0           8 CLOSED       PROVISIONED                /dev/raw/raw4
           0           5 CLOSED       MEMBER                     /dev/raw/raw5
           2           1 CACHED       MEMBER         DATAG2_0001 /dev/raw/raw7
           2           0 CACHED       MEMBER         DATAG2_0000 /dev/raw/raw6

SQL> select instance_number, instance_name from v$instance;

INSTANCE_NUMBER INSTANCE_NAME
--------------- --------------------------------
              1 +ASM1

由於節點1上的ASM磁碟組1無法MOUNT，因此可以看到/dev/raw/raw4和/dev/raw/raw5兩個磁碟對應的GROUP_NUMBER是0，且MOUNT_STATUS是CLOSED，而raw4對應的HEADER_STATUS也是PROVISIONED，顯然就是這個錯誤的狀態值導致當前節點無法MOUNT磁碟組。

由於另外一個例項一直沒有關閉過，因此雖然磁碟頭的狀態不正常，但是並不影響這個磁碟組的正常使用，而如果這時對ASM例項進行重啟，則這個磁碟組必然無法再次MOUNT。

根據Oracle的文件的描述，PROVISIONED和CANDIDATE狀態有所區別，二者雖然表示的都是這個磁碟為候選磁碟，不屬於任何一個磁碟組，不過CANDIDATE是正常的候選狀態，而PROVISIONED則說明磁碟經過特殊的處理，比如作業系統工具對磁碟進行過特殊的操作。

既然這個磁碟的狀態是PROVISIONED，那麼能否透過再次新增這個磁碟到磁碟組，使得磁碟頭的狀態變成正常。於是嘗試在問題節點再次新增這個磁碟，但是由於磁碟組處於NOMOUNT狀態，導致新增操作失敗，而嘗試在目前正常工作的節點新增磁碟，結果同樣報錯：

SQL> alter diskgroup datag1 add disk '/dev/raw/raw4';
alter diskgroup datag1 add disk '/dev/raw/raw4'
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15029: disk '/dev/raw/raw4' is already mounted by this instance

看來常規手段已經無法解決這個問題，那麼現在只剩兩個辦法，一是重建ASM磁碟，二是直接修改ASM磁碟頭資訊。

重建意味著較長的停機時間，既是客戶當前環境中配置了DATA GUARD，重建ASM磁碟組也不是一個輕鬆的事情。當前的PRIMARY資料庫和STANDBY資料庫都是兩節點的RAC環境，而在資料庫中還配置STREAM的CAPTURE，這本身使得資料庫架構異常複雜，進行SWITCHOVER的難度相對也比較大。而且對於當前執行的節點而言，一旦關閉，很有可能導致ASM磁碟無法MOUNT，這就會導致原本計劃中的SWITCHOVER變成FAILOVER，甚至有可能損失ONLINE REDO LOGFILE的風險，因此無論從哪個角度看，重建都不是一個最佳的解決方案，顯然如果能直接將ASM磁碟的頭資訊改寫正確，這無疑是最直接代價最小的解決方案。