應用環境描述一、硬體1、 伺服器：2臺dell r610—16G記憶體、2顆6核xeon cpu、2個146G sas盤，做了raid12、 儲存：dell MD3220 24個300G硬碟3、 儲存連線：6GB HBA卡，2個通道都連線了二、軟體1、 系統：64位centos 5.52、 系統核心版本：Linux rac1 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux3、 asm軟體:oracleasm-2.6.18-194.el5-2.0.5-1.el5.x86_64.rpm、oracleasm-support-2.1.7-1.el5.x86_64.rpm、oracleasmlib-2.0.4-1.el5.x86_64.rpm4、 資料庫軟體：linux.x64_11gR2_database_1of2.zip、linux.x64_11gR2_database_2of2.zip5、 叢集軟體：linux.x64_11gR2_grid.zip故障描述

一、故障前的情況：1、 叢集例項正常執行2、 asm能用asmcmd檢視目錄和檔案3、 資料庫例項正常4、 監聽器正常5、 客戶端遠端連線正常6、 多路徑訪問正常7、 /dev/oracleasm/disks目錄的下的檔案全部存在二、故障的起因：1、 打算模擬伺服器失效2、 直接重啟兩個伺服器 init 6三、故障現象：1、 兩個伺服器的asm例項都沒有啟動成功2、 兩個伺服器的oracle例項都沒有啟動成功3、 Crs等程序啟動幾個，但基本上不能正常工作4、 手動啟動crs，失敗5、 以grid使用者手動連線例項，強制啟動，失敗故障基本原因判斷資料庫資料檔案、叢集軟體所需的ocr檔案都儲存在asm設定的共享儲存中，由於叢集軟體（包括asm例項）啟動失敗而最終也導致資料庫例項啟動失敗。處理過程

一、定位故障點：1、檢視系統程序，發現ASM程序沒有起來。但有少許grid相關的程序，如下圖所示：
2、手動執行 /u01/app/grid/bin/crsctl start crs 失敗3、檢視裝置檔案目錄 /dev/mapper,發現共享儲存的分割槽全部存在

[[email protected] ~]# ll /dev/mapper/total 0crw------- 1 root root 10, 63 Jul 24 00:00 controlbrw-rw---- 1 root disk 253, 0 Jul 24 00:01 mpath13brw-rw---- 1 root disk 253, 10 Jul 24 00:01 mpath13p1 brw-rw---- 1 root disk 253, 11 Jul 24 00:01 mpath13p2brw-rw---- 1 root disk 253, 12 Jul 24 00:01 mpath13p3brw-rw---- 1 root disk 253, 13 Jul 24 00:01 mpath13p5brw-rw---- 1 root disk 253, 14 Jul 24 00:01 mpath13p6brw-rw---- 1 root disk 253, 15 Jul 24 00:01 mpath13p7brw-rw---- 1 root disk 253, 16 Jul 24 00:01 mpath13p8brw-rw---- 1 root disk 253, 1 Jul 24 00:01 mpath14brw-rw---- 1 root disk 253, 3 Jul 24 00:01 mpath14p1brw-rw---- 1 root disk 253, 4 Jul 24 00:01 mpath14p2brw-rw---- 1 root disk 253, 5 Jul 24 00:01 mpath14p3brw-rw---- 1 root disk 253, 6 Jul 24 00:01 mpath14p5brw-rw---- 1 root disk 253, 7 Jul 24 00:01 mpath14p6brw-rw---- 1 root disk 253, 8 Jul 24 00:01 mpath14p7brw-rw---- 1 root disk 253, 9 Jul 24 00:01 mpath14p8brw-rw---- 1 root disk 253, 2 Jul 24 00:01 mpath15

4、初步懷疑是asm磁碟組出故障了，於是執行 oracleasm listdisks，發現輸出只有一行，可實際上是10多行的。

[[email protected] ~]# oracleasm listdisksDATA06

5、執行oracleasm scandisks掃描，再次檢視輸出磁碟，還是隻有一個。查了網上的資料，也有這種情況，別人的經驗是多執行幾次asm磁碟掃描就出來了，但對我這個情況無效。6、當我們初始化建立asm磁碟組時，使用命令 oracleasm createdisk OCR1 /dev/mapper/mpath14p1 執行成功後，將在目錄/dev/oracleasm/disks目錄生成OCR1這個檔案，檔名就是asm的磁碟名；建立多少asm磁碟，就會有多少同名檔案。進入目錄/dev/oracleasm/disks，檢視一下，只剩下一個塊裝置檔案DATA06,其餘的全部不見了。

[[email protected] ~]# ll /dev/oracleasm/disks/total 0brw-rw---- 1 grid asmadmin 8, 22 Jul 24 00:01 DATA06

與oracleasm listdisks 輸出的結果完全一致，由此可知asm磁碟組與作業系統這個目錄有直接的關聯。這幾者的關係可以如下圖示識： 現在要做的事情是能不能恢復餘下的磁碟檔案。二、處理方法1、先上網搜尋一下吧，搜出來不少，都是建議用dd清理磁碟，然後再用oracleasm createdisk 重新建立磁碟組。但我擔心這樣做，asm磁盤裡面的資料會全部丟失，沒敢這樣嘗試。2、打電話問我原來的同事，他現在轉行做dba了。他告訴我，看看是不是裝置檔案的許可權問題，我到伺服器上去檢視，發現一個機器的/dev/mapper/mpath* 的屬主是 root:disk,而另一個伺服器相應的目錄屬主卻是grid:oinstall。按照他的建議，我在檔案/etc/rc.local寫入了行“chown –R grid:oinstall”，然後重啟系統，檢視目錄確實屬主按我的意願變成grid：root，但asm磁碟仍然不能識別，看來問題不在這裡。3、在多個qq群傳送訊息，有說許可權問題的，也有建議oracleasm scandisk 的。還有的人認為oracleasm服務沒有執行起來。還有的人說是裸裝置許可權問題，我可是沒有使用裸裝置啊，開啟檔案/etc/sysconfig/rawdevices,沒有任何生效的文字行（全部被註釋上了），這應診了沒有使用裸裝置。搞了好幾天，沒得進展。一天睡在床上，有想起這個問題，既然/dev/oracleasm/disks有DATA06這個檔案，能不能手工建立一些呢（即丟失的那些檔案），於是又爬起來。但當我手動執行touch /dev/oracleasm/disks/DATA08時，提示沒有許可權。看來，只能用mknod之類的命令才可以在這個目錄建立檔案。念頭一轉，又想：既然DATA06這個檔案存在，可能會在某些檔案中有記錄吧？執行grep DATA06 /etc -r 全路徑搜尋，還真搜到一個檔案 /etc/blkid/blkid.tab,這個檔案的如下：

[[email protected] ~]# more /etc/blkid/blkid.tab/dev/sda7/dev/sda6/dev/sda5/dev/sda3/dev/sda2/dev/sda1/u01/swapfile/dev/mapper/mpath14p8/dev/mapper/mpath15p8<device DEVNO="0xfd0e" TIME="1311441535" LABEL="DATA06" TYPE="oracleasm">/dev/mapper/mpath14p6/dev/mapper/mpath14p5/dev/mapper/mpath15p5/dev/mapper/mpath14p3/dev/mapper/mpath15p3/dev/mapper/mpath14p2/dev/mapper/mpath15p2/dev/mapper/mpath14p1/dev/mapper/mpath15p1/dev/sdb1/dev/sdb2vice>/dev/sdb3vice>/dev/sdb5vice><device DEVNO="0x0816" TIME="1311441535" LABEL="DATA06" TYPE="oracleasm">/dev/sdb6/dev/sdb8/dev/sdc1/dev/sdc2vice>/dev/sdc3vice>/dev/sdc5vice>/dev/sdc8vice>/dev/sde1/dev/sde2vice>/dev/sde3vice>/dev/sde5vice><device DEVNO="0x0846" TIME="1311441536" LABEL="DATA06" TYPE="oracleasm">/dev/sde6/dev/sde8/dev/sdf1/dev/sdf2vice>/dev/sdf3vice>/dev/sdf5vice>/dev/sdf8vice>

從輸出能看出一些端倪，凡是label為空的，就是asm磁碟丟失的。照這個思路，我手動在這個檔案改了對應的3行，使其label=“DATA08”。DATA08是當時用oracleasm createdisk創建出來，預留下來的。因為沒有資料存在這個DATA08磁碟，所以就是破壞了，也無關緊要。接著執行oracleasm scandisks ; 再 oracleasm listdisks 還是沒有任何變化，看來這招也不靈。最後重啟系統，看是否有效，還是一樣。後來才知，/etc/blkid/blkid.tab檔案的內容是執行blkid後從系統目錄/dev下讀入資料再自動生成的。難道只得重新推到再來一次？不甘心啊！倒不是怕資料丟失，而是擔心下次這個問題再次發生。再準備推到重來之前，我再來試試建立一個asm磁碟。還是拿沒有使用的/dev/mapper/mpath14p8分割槽來做，反正做壞了，也沒什麼影響。當執行oracleasm createdisk DATA08 /dev/mapper/mpath14p8,沒有成功，其輸出為：

Device "/dev/mapper/mpath14p8" is already labeled for ASM disk“”

這個輸出給我很好的提示，它說明了asm 磁碟標籤是存在的，但其值為空（它本來的值應該是DATA08）。於是我就思量，能不能強制把它由空值改成原來的值呢？不知道怎麼改oracle asm磁碟標籤，不過這難不倒咱。開啟檔案 /etc/init.d/oracleasm瞧瞧，乖乖，找到了呢.看下面一段函式：

force_relabel_disk(){    OLD="$1"    NEW="$2"    echo -n "Renaming disk \"${OLD}\" to \"${NEW}\": "    "${ORACLEASM}" renamedisk -f -v -l "${ORACLE_ASMMANAGER}" "${OLD}" \        "$2" 1>>/var/log/oracleasm 2>&1    if_fail "$?" "Unable to rename disk \"${OLD}\" see /var/log/oracleasm"}

紅色字型這行，就是強制性改asm磁碟標籤的語法。迫不及待，馬上執行 oracleasm renamedisk -f /dev/mapper/mpath14p8 DATA08 ，很順利進行下去了。現在切換到目錄/dev/oracleasm/disks，裝置檔案DATA08出現了，心裡一陣狂寫啊！在另一個主機上執行oracleasm scandisk ,接著執行oracleasm listdisks ，看見DATA08閃耀登場。由此可以預計，只要按以前的標籤名，把對應的asm磁碟強制改名，就應該可以恢復。先不急於把所有的asm磁碟標籤恢復，從ocr所在的磁碟標籤做起。本案的ocr用了兩個asm 磁碟，其名稱為OCR1、OCR2（幸虧以前安裝rac的時候，做了螢幕錄影），執行下面兩條命令：

oracleasm renamedisk -f /dev/mapper/mpath14p1 OCR1oracleasm renamedisk -f /dev/mapper/mpath15p1 OCR2

成功執行後，用 oracleasm scandisks掃描，檢查目錄/dev/oracleasm/disks,檔案OCR1、ORC2都存在了；檢查 oracleasm listdisks的輸出，確實有OCR1和OCR2.Ocr恢復了，可以試著啟動crs.以root命令執行 crsctl start crs ,回車後，系統一陣沉默，上個廁所回來，執行完畢返回shell提示符下。趕緊ps auxww|grep –I asm檢視程序，asm例項確實起來了.切換到grid使用者，執行asmcd，順利進入互動模式，ASMCMD>ls 輸出為：

ASMCMD> lsDGCRS/

注：DGCRS是由OCR1、OCR2兩者合併而成。再另一個伺服器上，啟動crs，asm例項正常執行起來了。現在，可以放心的強制更改餘下的asm標籤，完畢後目錄的檔案日下：

[[email protected] dev]# ll /dev/oracleasm/diskstotal 0brw-rw---- 1 grid oinstall   8, 18 Jul 26 17:05 DATA02brw-rw---- 1 grid oinstall   8, 19 Jul 26 17:05 DATA03brw-rw---- 1 grid oinstall   8, 21 Jul 26 17:05 DATA05brw-rw---- 1 grid oinstall   8, 22 Jul 24 22:31 DATA06brw-rw---- 1 grid oinstall   8, 24 Jul 26 17:05 DATA08brw-rw---- 1 grid oinstall   8, 34 Jul 26 17:05 DATA12brw-rw---- 1 grid oinstall   8, 35 Jul 26 17:05 DATA13brw-rw---- 1 grid oinstall   8, 37 Jul 26 17:05 DATA15brw-rw---- 1 grid oinstall 253, 14 Jul 24 22:41 DATA16brw-rw---- 1 grid oinstall   8, 40 Jul 26 17:00 DATA18brw-rw---- 1 grid oinstall   8, 17 Jul 26 17:05 OCR1brw-rw---- 1 grid oinstall   8, 33 Jul 24 22:32 OCR2

確認無誤後，聯絡相關人員告知要啟動資料庫了。再次檢查ORACLE_SID、asm磁碟標籤等，深呼吸一下，緩慢地輸入/u01/app/grid/bin/srvctl start database -d DD4QIGOU 回車，起身離座喝口統一鮮橙多（估計有塑化劑）。估計資料庫啟得差不多了，回坐檢視，oracle例項全部正常起來。不過有一點意外，就是伺服器交換了各自的例項（rac1執行的例項是db4qigou_2、而rac2執行的例項是db4qigou_1）；這不要緊，關閉各種的例項，在rac1上執行$srvctl start instance -d DB4QIGOU -i DB4QIGOU_1 -n rac1 ，rac2上執行srvctl start instance -d DB4QIGOU -i DB4QIGOU_2 -n rac2就扳過來了。

補充：oracle官方站點有建議修改 /etc/sysconfig/oracleasm檔案的掃描順序，但在本例無效。