ASM磁碟組ORA-15042 ORA-15096

今天跟大家分享一個ASM磁碟組損壞的案例，此案例來自於一個網友。由於是保密客戶，不能拿到資料，所以這裡只是在自己的環境中模擬此現象並給出解決方案。

從Oracle 10g中，Oracle推出ASM（自動儲存管理）功能，用於替換基於主機的儲存管理軟體，使得Oracle RAC執行不在依賴於第三方的儲存管理軟體（如hacmp，sfrac）。在10G中，ASM的功能和穩定性還不完善，並沒有被大規模使用。

但是在11G版本中，ASM已經被大規模使用，成為叢集的核心儲存管理解決方案。同時ASM這個黑匣子也逐漸的被大家認識，今天我們就給大家分享一起ASM磁碟組不能掛載的案例。

ASM磁碟組有三種冗餘方式：External Redundancy、Normal Redundancy、High Redundancy。其中的冗餘機制這裡就不過多介紹了，擁有冗餘的磁碟組就可以高枕無憂了嗎？肯定不是，冗餘的機制只能保證部分故障的解決，還不足以讓我們高枕無憂。

就如我們今天的分享案例，哪怕你有normal的冗餘方式，也只能事出無奈、束手無策，特別是在一些OLAP系統中，幾十T的資料很正常，當故障來臨時，哪怕通過備份來還原，這個時間也是無法容忍的。唯有對ASM原理足夠的瞭解，才能讓我們在故障時，通過一些非常規的手段修復。

ASM和普通的檔案系統一樣，有自己的後設資料，並且ASM的後設資料庫是可以直接通過KFED來檢視和編輯的，今天我們用到的就是PST後設資料。

我們簡單描述一下：

• PST對於ASM非常重要，在讀取其他ASM metadata之前會先檢查PST，當mount diskgroup時，GMON程式會讀取diskgroup中所有磁碟去找到和確認PST，通過PST可以確認哪些磁碟是可以ONLINE使用的，哪些是OFFLINE的。

• PST位於磁碟的第一個au上，但並不是每塊磁碟上都有PST。磁碟組映象的不同，PST的個數也不同，如下：

  External Redundancy一般有一個PST

  Normal Redundancy至多有個3個PST

  High Redundancy 至多有5個PST

下面有請我們今天的主角出場：

NORMAL磁碟組中有1個failgroup意外offline(如現在市面上的一體機1個儲存節點意外重啟)，在這個failgroup恢復回來重新成功online之前，另外一個failgroup中有一塊磁碟損壞了，此時悲劇就發生了，即使被offline的failgroup還原回來，也不能mount磁碟組。因為我們之前介紹的ASM重要後設資料PST認為這些盤的狀態不是可正常訪問的。

 

 

 

 

 

構建NORMAL冗餘磁碟組

 

 

 

 

為了便於觀察恢復效果，跟蹤某條記錄的變化，在offline primary extent所在磁碟後，更新這條資料，然後破壞其secondary extent所在磁碟，最後驗證該事務是否丟失。

這裡手動建立一張rescureora的測試表，並檢視其中一行記錄物理存放位置。

通過指令碼找到資料塊與ASM磁碟的對映關係，由於是normal冗餘，此處會看到兩副本，LXN_KFFXP為0的是primary extent在1號disk上，為1的是secondary extent在4號disk上，稍後我們就模擬offline 1號disk所在fg，並且破壞4號盤。

 

 

 

 

 

通過GMON日誌分析PST位置

 

 

 

 

 

從gmon trace可以發現，該磁碟組PST在0、2、4號磁碟上。通過kfed也可以驗證：

 

 

模擬故障現象

 

 

 

offline fg2 

 

 

fg2為primary extent所在的failgroup，此時手動offline，模擬生產環境的伺服器關機。

SQL> ALTER DISKGROUP TEST offline disks in failgroup fg2;

Diskgroup altered.

此時gmon日誌中，會生成最新的PST資訊，如下：

 

 

更新資料 

 

 

此處更新資料只是為了最後驗證資料的有效性。

 

 

手動破壞4號磁碟 

 

 

這裡採用的dd命令，如果在12C中開啟afd後，dd命令會自動過濾。

[grid@rescureora1 trace]$ dd if=/dev/zero of=/dev/asm-test-diskg bs=4096 count=1 conv=notrunc
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000306284 s, 13.4 MB/s

 

 

故障出現 

 

 

磁碟組已經無法mount：

通過gmon trace觀察此時的PST分佈情況：

 

解決方案

 

檢視PST中的磁碟狀態 

 

 

 

 

修改磁碟狀態 

 

 

這裡將磁碟0和1的狀態值修改為127即可。

 

 

掛載磁碟組 

 

 

PST修復完成，嘗試mount磁碟組：

SQL> alter diskgroup test mount force;
alter diskgroup test mount force
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15096: lost disk write detected
ORA-15042: ASM disk "4" is missing from group number "2"

這裡報寫丟失，跟之前的報錯已經不一樣，此時是由於磁碟組在掛載時做recover報錯，那麼很簡單，跳過recover那一步就可以。

此時報錯稍微有些不同，磁碟組在進行recover的時候報錯，checkpoint為seq=7,block=1474

NOTE: starting recovery of thread=1 ckpt=7.1474 group=2 (TEST)
NOTE: BWR validation signaled ORA-15096
Errors in file /u01/app/grid/diag/asm/+asm/+ASM/trace/+ASM_ora_4035.trc:
ORA-15096: lost disk write detected
ORA-15042: ASM disk "4" is missing from group number "2"

檢視ACD後設資料：

修改ACD，加大ckpt的seq為9：

 

 

修復ACD後設資料 

 

 

修復ACD後設資料：

kfed merge /dev/asm-test-diske aun=4 blkn=0 text=acd.txt

 

 

掛載磁碟組 

 

 

再次嘗試mount磁碟組，發現磁碟組掛載正常。

SQL> alter diskgroup test mount force;

Diskgroup altered.

 

 

啟動資料庫 

 

 

如果在正常環境中，此時會出現資料不一致的情況，當然，如果有歸檔日誌在，那麼就可以向本案例一樣，完美的解決。

SQL> recover database;
Media recovery complete.
SQL> alter database open;