鼎甲公司使用kfed修復ASM磁盤組故障案例
發布人：scutech 發布日期：2013-05-21 15:55:12 點擊數：6648
前言
3月30日廣州某單位Oracle RAC的數據庫在添加新磁盤后出現故障，導致磁盤組無法掛載，該單位尋求Oracle公司解決，但費用非常昂貴，他們抱著僥幸的心理找到了鼎甲科技。廣州鼎甲計算機科技有限公司作為國內頂尖的數據容災備份廠商，鼎甲科技憑借其雄厚的技術實力以及完善的服務體系，與各種行業用戶有著緊密的合作關系。鼎甲科技的技術人員在最短時間內，以零成本的服務，成功解決了此故障，讓該單位的業務一切恢復正常，該單位對鼎甲科技的專業技術實力及服務質量給予高度贊揚及認可。下面給大家分享本案例使用kfed修復ASM磁盤組故障過程。
一、故障現象
鼎甲公司了解情況后立刻派工程師前往探究，通過對ASM的v$asm_disk視圖的檢查，發現磁盤狀態全部顯示正常；執行“alterdiskgroup dgdata mount;”顯示成功，但接著查詢v$asm_diskgroup，該磁盤組仍處于dismounted的狀態。檢查alert日志，看到磁盤組報告錯誤，然后在mounted之后隨即被dismount了。alert日志如下：
Sat Mar 30 10:51:592013 NOTE: erasingincomplete header on grp 1 disk VOL19 NOTE: cache openingdisk 0 of grp 1: VOL10 label:VOL10 NOTE: F1X0 found ondisk 0 fcn 0.4276074 NOTE: cache openingdisk 1 of grp 1: VOL11 label:VOL11 NOTE: cache openingdisk 2 of grp 1: VOL12 label:VOL12 NOTE: cache openingdisk 3 of grp 1: VOL13 label:VOL13 NOTE: cache openingdisk 4 of grp 1: VOL14 label:VOL14 NOTE: cache openingdisk 5 of grp 1: VOL3 label:VOL3 NOTE: cache openingdisk 6 of grp 1: VOL4 label:VOL4 NOTE: cache openingdisk 7 of grp 1: VOL5 label:VOL5 NOTE: cache openingdisk 8 of grp 1: VOL6 label:VOL6 NOTE: cache openingdisk 9 of grp 1: VOL7 label:VOL7 NOTE: cache openingdisk 10 of grp 1: VOL8 label:VOL8 NOTE: cache openingdisk 11 of grp 1: VOL9 label:VOL9 NOTE: cache openingdisk 12 of grp 1: VOL1 label:VOL1 NOTE: cache openingdisk 13 of grp 1: VOL2 label:VOL2 NOTE: cache openingdisk 14 of grp 1: VOL15 label:VOL15 NOTE: cache openingdisk 15 of grp 1: VOL16 label:VOL16 NOTE: cache openingdisk 16 of grp 1: VOL17 label:VOL17 NOTE: cache openingdisk 17 of grp 1: VOL18 label:VOL18 NOTE: cachemounting (first) group 1/0x36E8615F (DGDATA) * allocate domain1, invalid = TRUE kjbdomatt send tonode 1 Sat Mar 30 10:51:592013 NOTE: attached torecovery domain 1 Sat Mar 30 10:51:592013 NOTE: startingrecovery of thread=1 ckpt=75.5792 group=1 NOTE: advancingckpt for thread=1 ckpt=75.5792 NOTE: cacherecovered group 1 to fcn 0.5174872 Sat Mar 30 10:51:592013 NOTE: opening chunk1 at fcn 0.5174872 ABA NOTE: seq=76blk=5793 Sat Mar 30 10:51:592013 NOTE: cachemounting group 1/0x36E8615F (DGDATA) succeeded WARNING: offliningdisk 16.3915944441 (VOL17) with mask 0x3 NOTE: PST update:grp = 1, dsk = 16, mode = 0x6 Sat Mar 30 10:51:592013 ERROR: too manyoffline disks in PST (grp 1) NOTE: cache closingdisk 16 of grp 1: VOL17 label:VOL17 NOTE: cache closingdisk 16 of grp 1: VOL17 label:VOL17 Sat Mar 30 10:51:592013 SUCCESS: diskgroupDGDATA was mounted Sat Mar 30 10:51:592013 ERROR:PST-initiated MANDATORY DISMOUNT of group DGDATA NOTE: cachedismounting group 1/0x36E8615F (DGDATA) Sat Mar 30 10:51:592013 NOTE: halting all I/Osto diskgroup DGDATA Sat Mar 30 10:51:592013 kjbdomdet send tonode 1 detach from dom 1,sending detach message to node 1 Sat Mar 30 10:51:592013 Dirty detachreconfiguration started (old inc 2, new inc 2) List of nodes: 0 1 Global Resource Directory partially frozen fordirty detach * dirty detach -domain 1 invalid = TRUE 10 GCS resources traversed, 0 cancelled 4014 GCS resources on freelist, 6138 on array,6138 allocated Dirty DetachReconfiguration complete Sat Mar 30 10:51:592013 freeing rdom 1 Sat Mar 30 10:51:592013 WARNING: dirtydetached from domain 1 Sat Mar 30 10:51:592013 SUCCESS: diskgroupDGDATA was dismounted Received detach msg from node 1 for dom 2
憑著ASM知識的了解和經驗，能大概知道是某個盤存在故障而被離線，進而導致磁盤組由于缺少磁盤而被卸載。
目前最大的問題就是，磁盤組無法掛載，導致無法對磁盤組進行任何操作，即使想刪除可能存在故障的磁盤都沒有辦法。通過對某單位技術員溝通，了解到導致故障的操作：首先在磁盤組中添加3個新磁盤，報錯，隨后再嘗試將新磁盤單獨加入，仍報錯，此后發現磁盤組被卸載。
通過查閱、分析和對比相關的信息資料，在metalink上看到一些類似情況的解決辦法，使用dd清空故障磁盤頭部，或者強制將故障磁盤加入新的磁盤組，使原有磁盤組無法識別原有故障盤，之后便可以成功加載。為了避免造成進一步損壞，我與對方單位已經達成共識，在有確定可行的方案之前，不能作任何修改操作。
二、故障分析
開始檢查日志，查找最開始導致問題的操作和相關日志信息。
節點1，第一次同時添加VOL17、VOL18、VOL19時沒有明顯錯誤，但有一個警告“WARNING: offlining disk 18.3915945713 (VOL19) withmask 0x3”，判斷可能VOL19添加時出現問題。日志如下：
Fri Mar 29 18:31:372013 SQL> alterdiskgroup DGDATA add disk 'ORCL:VOL17','ORCL:VOL18','ORCL:VOL19' Fri Mar 29 18:31:372013 NOTE:reconfiguration of group 1/0x44e8663d (DGDATA), full=1 Fri Mar 29 18:31:382013 NOTE: initializingheader on grp 1 disk VOL17 NOTE: initializingheader on grp 1 disk VOL18 NOTE: initializingheader on grp 1 disk VOL19 NOTE: cache openingdisk 16 of grp 1: VOL17 label:VOL17 NOTE: cache openingdisk 17 of grp 1: VOL18 label:VOL18 NOTE: cache openingdisk 18 of grp 1: VOL19 label:VOL19 NOTE: PST update:grp = 1 NOTE: requestingall-instance disk validation for group=1 Fri Mar 29 18:31:382013 NOTE: diskvalidation pending for group 1/0x44e8663d (DGDATA) SUCCESS: validateddisks for 1/0x44e8663d (DGDATA) Fri Mar 29 18:31:402013 NOTE: requestingall-instance membership refresh for group=1 Fri Mar 29 18:31:402013 NOTE: membershiprefresh pending for group 1/0x44e8663d (DGDATA) SUCCESS: refreshedmembership for 1/0x44e8663d (DGDATA) Fri Mar 29 18:31:432013 WARNING: offliningdisk 18.3915945713 (VOL19) with mask 0x3 NOTE: PST update:grp = 1, dsk = 18, mode = 0x6 NOTE: PST update:grp = 1, dsk = 18, mode = 0x4 NOTE: cache closingdisk 18 of grp 1: VOL19 NOTE: PST update:grp = 1 NOTE: requestingall-instance membership refresh for group=1 Fri Mar 29 18:31:492013 NOTE: membershiprefresh pending for group 1/0x44e8663d (DGDATA) NOTE: cache closingdisk 18 of grp 1: VOL19 SUCCESS: refreshedmembership for 1/0x44e8663d (DGDATA) Received dirty detach msg from node 1 for dom1 Fri Mar 29 18:31:512013 Dirty detachreconfiguration started (old inc 4, new inc 4) List of nodes: 0 1 Global Resource Directory partially frozen fordirty detach * dirty detach -domain 1 invalid = TRUE 2817 GCS resources traversed, 0 cancelled 1981 GCS resources on freelist, 7162 on array,6138 allocated 1719 GCS shadows traversed, 0 replayed Dirty DetachReconfiguration complete Fri Mar 29 18:31:512013 NOTE: PST enablingheartbeating (grp 1) Fri Mar 29 18:31:512013 NOTE: SMON startinginstance recovery for group 1 (mounted) NOTE: F1X0 found ondisk 0 fcn 0.4276074 NOTE: startingrecovery of thread=1 ckpt=39.5722 group=1 NOTE: advancingckpt for thread=1 ckpt=39.5722 NOTE: smon didinstance recovery for domain 1 Fri Mar 29 18:31:532013 NOTE: recoveringCOD for group 1/0x44e8663d (DGDATA) SUCCESS: completedCOD recovery for group 1/0x44e8663d (DGDATA) Fri Mar 29 18:32:182013
同一時間可看到節點2有報錯“ERROR:group 1/0x44e86390 (DGDATA): could not validate disk 18”，隨后VOL19（即disk18）被離線并導致磁盤組被卸載，部分錯誤信息與后來磁盤組無法加載的日志吻合。日志如下：
Fri Mar 29 18:31:372013 NOTE:reconfiguration of group 1/0x44e86390 (DGDATA), full=1 NOTE: diskvalidation pending for group 1/0x44e86390 (DGDATA) ERROR: group1/0x44e86390 (DGDATA): could not validate disk 18 SUCCESS: validateddisks for 1/0x44e86390 (DGDATA) NOTE: membershiprefresh pending for group 1/0x44e86390 (DGDATA) NOTE: PST update:grp = 1, dsk = 18, mode = 0x4 Fri Mar 29 18:31:432013 ERROR: too manyoffline disks in PST (grp 1) Fri Mar 29 18:31:432013 SUCCESS: refreshedmembership for 1/0x44e86390 (DGDATA) ERROR: ORA-15040thrown in RBAL for group number 1 Fri Mar 29 18:31:432013 Errors in file/opt/app/oracle/admin/+ASM/bdump/+asm2_rbal_14019.trc: ORA-15040:diskgroup is incomplete ORA-15066: offliningdisk "" may result in a data loss ORA-15042: ASM disk"18" is missing NOTE: cache closingdisk 18 of grp 1: NOTE: membershiprefresh pending for group 1/0x44e86390 (DGDATA) NOTE: cache closingdisk 18 of grp 1: NOTE: cache openingdisk 16 of grp 1: VOL17 label:VOL17 NOTE: cache openingdisk 17 of grp 1: VOL18 label:VOL18 SUCCESS: refreshedmembership for 1/0x44e86390 (DGDATA) Fri Mar 29 18:31:502013 ERROR:PST-initiated MANDATORY DISMOUNT of group DGDATA NOTE: cachedismounting group 1/0x44E86390 (DGDATA) Fri Mar 29 18:31:512013 NOTE: halting allI/Os to diskgroup DGDATA Fri Mar 29 18:31:512013 kjbdomdet send tonode 0 detach from dom 1,sending detach message to node 0 Fri Mar 29 18:31:512013 Dirty detachreconfiguration started (old inc 4, new inc 4) List of nodes: 0 1 Global Resource Directory partially frozen fordirty detach * dirty detach -domain 1 invalid = TRUE 2214 GCS resources traversed, 0 cancelled 5528 GCS resources on freelist, 7162 on array,6138 allocated Dirty DetachReconfiguration complete Fri Mar 29 18:31:512013 WARNING: dirtydetached from domain 1 Fri Mar 29 18:31:512013 SUCCESS: diskgroupDGDATA was dismounted
由此判斷，很可能是添加磁盤時VOL19在節點2上存在權限問題：通常情況下是Oracle用戶沒有相關設備的訪問權限。根據此判斷，我在自己的虛擬機上運行RAC，并模擬這一錯誤：在節點1上設置好Oracle用戶對新增磁盤的訪問權限，在節點2上不作設置，然后添加新增磁盤。操作后果然出現幾乎相同的日志，但有一處差別：在我的模擬環境中日志有報告“ORA-15075:disk(s) are not visible cluster-wide”，而單位提供的日志沒有這一錯誤，因此仍無法斷定是同一問題。
后來，發現這單位的操作記錄下確實有出現ORA-15075的錯誤，證實了第一次添加磁盤失敗是由于權限問題造成的。圍繞這一個誤操作進行反復多次測試，發現在模擬環境中，即使出現該誤操作也不會導致磁盤組無法掛載。只要哪個節點設置好Oracle用戶對磁盤的訪問權限，該節點就可以成功掛載磁盤組。
隨后繼續模擬實際操作，失敗后再繼續輸入添加磁盤的命令，也不會出現任何進一步的故障，Oracle都會正確地報告“ORA-15029: disk '…' is already mounted by thisinstance”。這單位提供的操作記錄顯示，在第二次嘗試添加VOL17及VOL18時，Oracle正確報告ORA-15029，說明VOL17及VOL18已成功加入磁盤組。
但操作記錄顯示隨后的一次操作卻出現了異常，此時再次嘗試添加VOL17卻出現“ORA-15033: disk 'ORCL:VOL17' belongs todiskgroup "DGDATA"”的錯誤。這是一個異常的錯誤，根據前面多次測試得到的經驗，該錯誤表示的意思是“VOL17是屬于另一個磁盤組的，不能添加到指定的磁盤組，除非加上FORCE選項強制加入”。也就是說，第二次嘗試添加磁盤時VOL17還能被識別出是DGDATA磁盤組的，但第三次嘗試添加磁盤時卻沒被識別出來。此時日志也出現了異常情況：
Fri Mar 29 18:35:412013 SQL> alter diskgroupDGDATA add disk 'ORCL:VOL17' Fri Mar 29 18:35:412013 NOTE:reconfiguration of group 1/0x44e8663d (DGDATA), full=1 Fri Mar 29 18:35:412013 WARNING: ignoringdisk ORCL:VOL18 in deep discovery WARNING: ignoringdisk ORCL:VOL19 in deep discovery NOTE: requestingall-instance membership refresh for group=1 Fri Mar 29 18:35:412013 NOTE: membershiprefresh pending for group 1/0x44e8663d (DGDATA) SUCCESS: validateddisks for 1/0x44e8663d (DGDATA) NOTE: PST update:grp = 1, dsk = 16, mode = 0x4 Fri Mar 29 18:35:452013 ERROR: too manyoffline disks in PST (grp 1) Fri Mar 29 18:35:452013 SUCCESS: refreshedmembership for 1/0x44e8663d (DGDATA) ERROR: ORA-15040thrown in RBAL for group number 1 Fri Mar 29 18:35:452013 Errors in file/opt/app/oracle/admin/+ASM/bdump/+asm1_rbal_13974.trc: ORA-15040:diskgroup is incomplete ORA-15066:offlining disk "" may result in a data loss ORA-15042: ASM disk"16" is missing Fri Mar 29 18:35:452013 ERROR:PST-initiated MANDATORY DISMOUNT of group DGDATA NOTE: cache dismountinggroup 1/0x44E8663D (DGDATA) Fri Mar 29 18:35:452013 NOTE: halting allI/Os to diskgroup DGDATA Fri Mar 29 18:35:452013 kjbdomdet send tonode 1 detach from dom 1,sending detach message to node 1 Fri Mar 29 18:35:452013 Dirty detachreconfiguration started (old inc 4, new inc 4) List of nodes: 0 1 Global Resource Directory partially frozen fordirty detach * dirty detach -domain 1 invalid = TRUE 1291 GCS resources traversed, 0 cancelled 2347 GCS resources on freelist, 7162 on array,6138 allocated Dirty DetachReconfiguration complete Fri Mar 29 18:35:452013 freeing rdom 1 Fri Mar 29 18:35:452013 WARNING: dirtydetached from domain 1 Fri Mar 29 18:35:462013 SUCCESS: diskgroupDGDATA was dismounted
此時磁盤節點1的磁盤組也被卸載，可以判斷正是此時的異常導致了后來出現的故障。
由于在模擬環境上反復進行添加磁盤的操作并未重現出故障，此時只能判斷該故障很可能是Oracle的BUG，可能正好該添加磁盤的操作影響了Oracle對新磁盤的rebalance操作，隨后Oracle將該磁盤標記為離線，并導致磁盤組被卸載。與這單位技術員交流了測試結果，得知在單位的環境中節點2后來已經設置好Oracle用戶對磁盤的訪問權限，但故障依舊。此后我繼續做dd及強制把故障磁盤加入新磁盤組的測試。
隨后進行了一系列測試。由于測試環境下磁盤并不會出現故障，因此只能手動把磁盤組離線，然后進行“修復”后嘗試掛載磁盤組。嘗試了使用dd覆蓋“故障磁盤”的頭部，及把“故障磁盤”加入新磁盤組后刪除，都無法再掛載原加入的磁盤組。但在測試環境下，磁盤組無法掛載都會報告“ORA-15042:ASM disk "…" is missing”，而不像實際環境中報告掛載成功。對比了網上其他人使用dd及強制加入新磁盤組的文章，發現有一個很大差異：網上修復的案例都是使用“normalredundancy”方式的磁盤組，這種情況下磁盤組中存在冗余數據，所以一個磁盤出現故障并不會使磁盤組被卸載，在這個前提下許多操作都有可能進行。而單位的故障系統是使用了“externalredundancy”，數據在Oracle看來是沒有冗余的，這也是磁盤組目前無法掛載的一個原因。
基于上述情況，想到了2個解決方案。一個是查看Oracle有沒有強制掛載磁盤組的命令，也許會有這種命令提供給用戶進行故障修復。另一個是想到使用kfed可以修改磁盤頭信息，那么我找一個正常的磁盤修改下磁盤頭信息后恢復到故障盤，是否就能使故障盤被正確識別？隨后第一個辦法被否定了，查閱了資料發現只有11g有強制掛載磁盤組的選項，關鍵是只是“normal redundancy”的磁盤組才能使用。第二個辦法在昨天被破壞的模擬環境上進行測試，居然可以成功！將這個方法的操作過程發給這單位的技術員，讓他在自己的測試環境上進行驗證。
這個kfed修復磁盤頭的方法如下：找一個正常的磁盤，用kfed導出其磁盤頭信息，對比故障盤導出的磁盤頭信息，合并出一個修復后的故障盤磁盤頭信息，導入故障盤。例如正常的磁盤是/dev/rdsk/c1t0d0s3，故障盤是/dev/rdsk/c1t1d0s1，使用以下操作：
kfed read/dev/rdsk/c1t0d0s3 text=header0 kfed read/dev/rdsk/c1t1d0s1 text=header1 vimdiff header0header1 （...修改出一個“正確”的故障盤磁盤頭，另存為header1fix...） kfed merge/dev/rdsk/c1t1d0s1 text=header1fix
如果故障盤的磁盤頭沒有可用信息，需要把它加入新磁盤組后刪除，這樣其磁盤頭中就有新磁盤組的信息。
其中關鍵的需要修復的信息有：
kfdhdb.dsknum：磁盤在磁盤組中的序號，從0開始，如Oracle日志中的disk 18應該對應的數字為17
kfdhdb.grpname：磁盤組的名稱，如果是從新磁盤組中刪除，需要改為原磁盤組的名稱
kfdhdb.grpstmp.hi：磁盤組的時間截，需要從正常磁盤頭中復制
kfdhdb.grpstmp.lo：同上
不過后來收到單位技術員的反饋，故障系統上的VOL17、VOL18、VOL19磁盤頭都是正確的，說明這種方法不會起作用。
克隆故障環境
后來，提出了可以使用dd把故障系統的磁盤都拷貝出來，然后在此基礎上搭建測試環境，可以在克隆出的故障系統上進行研究。周三拿到了拷好的數據，使用iscsi加載到測試環境，運行oracleasm scandisks，開始在模擬環境上測試。
三、解決問題
使用kfed檢查了VOL17、VOL18、VOL19的磁盤頭，確實全部正常。把之前嘗試過的方法在該模擬環境上重新嘗試一遍，確實也都不奏效。需要想想其它辦法。
參考了文章：http://blog.csdn.net/tianlesoftware/article/details/6740716 ，先在磁盤組中找到KFBTYP_LISTHEAD，然后再找到KFBTYP_DISKDIR，可看到DISKDIR塊中包含有各磁盤的信息，其中VOL17的狀態與其它盤都不同：
kfddde[0].entry.incarn: 4 ; 0x024: A=0 NUMM=0x1
其它盤（包括VOL18、VOL19）都是：
kfddde[0].entry.incarn: 1 ; 0x024: A=1 NUMM=0x0
當時分析后認為應該可以通過修改VOL17的狀態，讓VOL17變回正常。 不過當時并沒有馬上嘗試，而是根據這個思路去找到PST表。與其修改VOL17的狀態，不如找到PST表把VOL17刪除掉。
PST表的解釋：Partner StatusTable. Maintains info ondisk-to-diskgroup membership.
根據http://blog.csdn.net/tianlesoftware/article/details/6743677 這個鏈接的內容，PST表應該存在于某個磁盤的AU=1位置。檢查了磁盤組中的所有磁盤，只有VOL10包含了PST表，但AU=1處并不包含任何有用的內容，它的類型是KFBTYP_PST_META。根據前面查找DISKDIR的經驗，繼續檢查AU=1,BLK=1處的數據，仍然是KFBTYP_PST_META，再繼續檢查AU=1,BLK=2，發現了KFBTYP_PST_DTA。繼續檢查其內容，很有規律：
kfdpDtaE[0].status: 117440512 ; 0x000: V=1 R=1 W=1 kfdpDtaE[0].index: 0 ; 0x004: CURR=0x0CURR=0x0 FORM=0x0 FORM=0x0 kfdpDtaE[0].partner[0]: 0 ; 0x008: 0x0000 kfdpDtaE[0].partner[1]: 0 ; 0x00a: 0x0000 kfdpDtaE[0].partner[2]: 0 ; 0x00c: 0x0000 ...... kfdpDtaE[0].partner[19]: 0 ; 0x02e: 0x0000 kfdpDtaE[1].status: 117440512 ; 0x030: V=1 R=1 W=1 kfdpDtaE[1].index: 0 ; 0x034: CURR=0x0CURR=0x0 FORM=0x0 FORM=0x0 kfdpDtaE[1].partner[0]: 0 ; 0x038: 0x0000 kfdpDtaE[1].partner[1]: 0 ; 0x03a: 0x0000 kfdpDtaE[1].partner[2]: 0 ; 0x03c: 0x0000 ...... kfdpDtaE[1].partner[19]: 0 ; 0x05e: 0x0000 kfdpDtaE[2].status: 83886080 ; 0x060: V=1 R=1 W=1 ......
直到檢查到kfdpDtaE [18].status開始變為0。與磁盤一一進行對應，0～15對應原有的16塊磁盤，16、17對應新增的VOL17、VOL18，而VOL19則由于權限問題沒有出現在表中。決定嘗試修改該表，將VOL17、VOL18從磁盤組中刪除：
ddif=/dev/oracleasm/disks/VOL10 of=vol10.save bs=1048576 count=10 kfed read/dev/oracleasm/disks/VOL10 aun=1 blkn=2 text=pst.data vi pst.data （...修改kfdpDtaE[16].status及kfdpDtaE[17].status為0，另存為pst.update...） kfed merge/dev/oracleasm/disks/VOL10 aun=1 blkn=2 text=pst.update
嘗試掛載磁盤組，如原來一樣報告成功，還得看日志：
Thu Apr 4 14:15:08 2013 SQL> alterdiskgroup dgdata mount Thu Apr 4 14:15:08 2013 NOTE: cacheregistered group DGDATA number=2 incarn=0x0c76f699 Thu Apr 4 14:15:08 2013 NOTE: Hbeat:instance first (grp 2) Thu Apr 4 14:15:13 2013 NOTE: startheartbeating (grp 2) Thu Apr 4 14:15:13 2013 NOTE: erasingincomplete header on grp 2 disk VOL17 NOTE: erasingincomplete header on grp 2 disk VOL18 NOTE: erasingincomplete header on grp 2 disk VOL19 NOTE: cache openingdisk 0 of grp 2: VOL10 label:VOL10 NOTE: F1X0 found ondisk 0 fcn 0.4276074 NOTE: cache openingdisk 1 of grp 2: VOL11 label:VOL11 NOTE: cache openingdisk 2 of grp 2: VOL12 label:VOL12 NOTE: cache openingdisk 3 of grp 2: VOL13 label:VOL13 NOTE: cache openingdisk 4 of grp 2: VOL14 label:VOL14 NOTE: cache openingdisk 5 of grp 2: VOL3 label:VOL3 NOTE: cache openingdisk 6 of grp 2: VOL4 label:VOL4 NOTE: cache openingdisk 7 of grp 2: VOL5 label:VOL5 NOTE: cache openingdisk 8 of grp 2: VOL6 label:VOL6 NOTE: cache openingdisk 9 of grp 2: VOL7 label:VOL7 NOTE: cache openingdisk 10 of grp 2: VOL8 label:VOL8 NOTE: cache openingdisk 11 of grp 2: VOL9 label:VOL9 NOTE: cache openingdisk 12 of grp 2: VOL1 label:VOL1 NOTE: cache openingdisk 13 of grp 2: VOL2 label:VOL2 NOTE: cache openingdisk 14 of grp 2: VOL15 label:VOL15 NOTE: cache openingdisk 15 of grp 2: VOL16 label:VOL16 NOTE: cachemounting (first) group 2/0x0C76F699 (DGDATA) NOTE: startingrecovery of thread=1 ckpt=94.5829 group=2 NOTE: advancing ckptfor thread=1 ckpt=94.5830 NOTE: cacherecovered group 2 to fcn 0.5174912 Thu Apr 4 14:15:13 2013 NOTE: opening chunk1 at fcn 0.5174912 ABA NOTE: seq=95blk=5831 Thu Apr 4 14:15:13 2013 NOTE: cachemounting group 2/0x0C76F699 (DGDATA) succeeded SUCCESS: diskgroupDGDATA was mounted Thu Apr 4 14:15:13 2013 NOTE: recoveringCOD for group 2/0xc76f699 (DGDATA) SUCCESS: completedCOD recovery for group 2/0xc76f699 (DGDATA)
有變化！VOL17及VOL18也跟VOL19一樣被清理了頭部，然后磁盤組不再報告VOL17需要離線，不再被卸載。此后檢查磁盤組狀態、磁盤狀態，一切正常。修改了pfile，啟動數據庫，成功打開。重新強制添加3個新磁盤，成功，一切穩定運行。
修復故障
在模擬環境中打開數據庫后，開始使用data pump導出部分業務數據。第二天安排部分應用開發人員上門檢查數據一致性。最后在生產系統上按模擬環境的方法進行修復，生產數據庫可正常打開，業務正常運行。
總結
本次ASM磁盤組故障問題反映了數據容災備份的主要性，要防止系統出現操作失誤或系統故障導致數據丟失，提前做好備份工作。
