某個數據庫環境中的ASM磁盤，由於歷史原因，全部配置爲沒有RAID信息的JBOD模式。今天在做產品升級，由於軟件需要，需要將原來加入到ASM中每個JBOD的磁盤配置爲RAID0。配置過程採用了rolling up的方式，每次對一個diskgroup中的一個failgroup的磁盤配置RAID。 大體步驟爲，以磁盤組ssddg的failgroup1爲例：
1、在ASM中操作，將failgroup1的磁盤全部offline；
2、在OS層將這些磁盤卸載；
3、配置failgroup1的磁盤爲raid0；
4、在OS層將這些磁盤加載；
5、在ASM中操作，將failgroup1的磁盤全部online。
有自信去做這件事是考慮到磁盤的數據不會受到影響，但是沒有考慮到元數據。於是遇到下面的問題：
所有節點通過存儲軟件正常加載上來已經做成RAID0的磁盤。然而在asm磁盤組中要把這些盤online上來時報了下面這個錯誤：
初步一看，以爲是自己操作的疏漏，共享磁盤在另一個RAC節點沒有加載，纔會報“磁盤不是集羣範圍可見”的錯誤；但檢查了/dev下的路徑以及通過dd命令確認可讀寫以後，可以確認這些盤都正常加載了，在OS層是集羣可見的。
下一步，只能去asm的alert日誌看看是否有更具體的報錯信息。在alert日誌的最後部分能看到上圖中的報錯。這個信息暫時不足以分析問題。向前追溯日誌一直到最開始的錯誤信息，可以看到，在online磁盤的操作發起以後，對應每個磁盤都有如下報錯：
報錯的字面意思很明白：磁盤頭元信息記錄的磁盤大小（763097M）要大於磁盤的實際大小（762496M）。緊跟着是如下信息：
到這裏，可以推出由於ASM元信息記錄的磁盤size超過了實際的size，磁盤在online時自檢失敗，online動作立刻終止。而後面的ORA-15282報錯，只是假象。
下面我想先把這個warning排除，來驗證我的推測。
在mos上沒有搜到該案例，只能用掌握的那點元數據的知識解決了。首先用kfed把盤頭的元數據讀取出來，重定向到文本。搜索
763097這個數字，找到了下面這行：
從條目的名稱kfdhdb.dsksize也可以看出這個條目記錄的是磁盤的大小。在創建ASM磁盤組時，會把盤的大小更新到這個條目，如果沒有指定size子句，一般都是磁盤（或者分區）的真實大小。操作系統識別到的磁盤大小可以用fdisk查看到，結果顯示兩者確實如報錯所說，大小有差異。產生差異的原因大家都應該猜到了，對盤做了RAID配置之後，可用大小發生了變化（可能是因爲RAID信息佔據了更多的磁盤大小，這塊誰可以解釋比較清楚歡迎提出）。
下面要解決ASM元信息與實際情況不一致的問題。考慮到ASM中可以通過resize命令改變ASM磁盤的可用大小，該操作包括兩個方面：更新ASM元信息（disk header和at表等等）和rebalance磁盤組的數據。但是這個操作前提是磁盤需要是online狀態。現在出問題這些磁盤online都會報錯，因此需要非常規手段先讓online這一步成功：
首先用kfed read命令將磁盤頭數據重定向到文本文件中，然後vi編輯本，將dsksize的值修改成762496，最後將改過的文本kfed merge到原磁盤。
做這個操作時我有幾點考慮：
1、asm磁盤頭的元信息在1號au的倒數第二個塊有備份，如果修改元數據發生意外，可以用kfed repair修復；
2、導出的元數據的文本，也可以作爲一個備份。
3、先對其中一塊磁盤做修改，試試效果。
對其中一塊ASM磁盤完成以上操作之後，在ASM中做online該單塊磁盤的動作就成功了。有了這個驗證之後，再將所有的ssddg磁盤的dsksize都改掉並在ASM中online起來。
用asmcmd命令行的lsdsk命令去看盤的大小時，發現確實是修改後的762496M。
之後在mos搜到了另外一個報錯，有相同的解決方法，見（doc id 1077175.1） ASM disk group mount fails with ORA15036: disk <name> is truncated。
有興趣的同學可以參考《解密Oracle ASM 內核》這本書中的ASM元信息AT表，stride等相關知識，去驗證：resize這一步除了更新磁盤頭部記錄的磁盤可用大小以外，還會更新at表最後一個塊記錄的可用au的信息等等元數據；而且resize動作發起之後，asm會對現有數據做rebalance。而手工使用kfed修改，只會改變磁盤頭部記錄的磁盤可用大小。
