Discover Your Missed ASM Disks(轉)

轉自（http://www.oracledatabase12g.com/archives/discover-your-missed-asm-disks.html ）

經常有網友在構建10g/11g中ASM儲存環境的時候遇到ASM磁碟無法識別的問題，雖然已經為儲存裝置賦予了適當的許可權，也為ASM例項修改了asm_diskstring初始化引數，可是在DBCA的ASM Diskgroup建立頁面裡就是無法顯示候選的ASM Disk磁碟。

實際上因為ASM儲存方式比起裸裝置或GPFS來說更為黑盒，我們也無法利用ASM instance中的一些動態效能檢視或內部檢視來排查造成這一問題的原因，使得這類問題顯得十分棘手。

下面我來介紹一種使用作業系統呼叫追蹤工具來排查ASM無法找到磁碟問題的方法。

[oracle@vrh1 raw]$ cd /dev/rdsk 

/* 演示中我們要用到的三個裸裝置位於/dev/rdsk下 */

[oracle@vrh1 rdsk]$ ls
hdisk1  hdisk2  hdisk3

[oracle@vrh1 rdsk]$ sqlplus / as sysdba

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SQL>  select path from v$asm_disk;
no rows selected

SQL> alter system set asm_diskstring='/dev/rdsk/hdisk*';
System altered.

SQL> select * from v$asm_disk;
no rows selected

/* 以上雖然設定了asm_diskstring引數，ASM instance依然無法在指定路徑下找到合適的裝置
    這是為什麼呢？！
*/

[oracle@vrh1 rdsk]$ ps -ef|grep rbal|grep -v grep
oracle   31375     1  0 15:40 ?        00:00:00 asm_rbal_+ASM1

/* 找出當前ASM例項中的rbal後臺程式  */

/* 針對該後臺程式做系統呼叫的trace，一般Linux上使用strace，而Unix上使用truss */

strace -f -o /tmp/asm_rbal.trc -p $OS_PID_OF_RBAL_BGPROCESS
truss  -ef -o /tmp/asm_rbal.trc -p $OS_PID_OF_RBAL_BGPROCESS

[oracle@vrh1 rdsk]$ strace -f -o /tmp/asm_rbal.trc  -p 31375
Process 31375 attached - interrupt to quit

/* 在另外一個終端視窗中開啟sqlplus登入ASM例項，執行對v$ASM_DISK或者X$KFDSK的查詢 */

SQL> select * from x$kfdsk;

no rows selected

/* 完成以上查詢後使用Ctrl+C中斷strace命令，並分析生成的system call trace */

/* 因為在不同Unix平臺上rbal後臺程式可能使用不同的system call function函式以達到相同的目的，
    所以在你的平臺上可能並不像在Linux上使用open和access2個關鍵詞搜尋就可以得到答案了！     */

[oracle@vrh1 rdsk]$ cat /tmp/asm_rbal.trc |egrep "open|access"
31375 open("/dev/rdsk", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 15
31375 access("/dev/rdsk/hdisk3", R_OK|W_OK) = -1 EACCES (Permission denied)
31375 access("/dev/rdsk/hdisk2", R_OK|W_OK) = -1 EACCES (Permission denied)
31375 access("/dev/rdsk/hdisk1", R_OK|W_OK) = -1 EACCES (Permission denied)

可以看到以上系統呼叫中使用access函式訪問候選的hdisk*ASM磁碟裝置時出現了”Permission denied”的問題，很顯然是因為許可權不足導致了ASM例項無法利用這部分的磁碟裝置，我們來糾正這一問題後再次嘗試:

[root@vrh1 ~]# chown oracle:dba /dev/rdsk/hdisk*

SQL> select path_kfdsk from x$kfdsk;

PATH_KFDSK
--------------------------------------------------------------------------------
/dev/rdsk/hdisk3
/dev/rdsk/hdisk2
/dev/rdsk/hdisk1

SQL> select path from v$asm_disk;

PATH
--------------------------------------------------------------------------------
/dev/rdsk/hdisk3
/dev/rdsk/hdisk1
/dev/rdsk/hdisk2

以上丟失ASM Disk診斷方法的原理是在查詢v$asm_disk或者x$kfdsk檢視時Oracle會讓RBAL這個ASM特別的後臺程式去訪問asm_diskstring引數指定路徑下的所有可用裝置，只要我們瞭解了在訪問過程中RBAL遭遇的問題，那麼一般來說都可以很簡單地予以解決，如果strace/truss也無法給予你任何啟示的話，也許你不得不去提交一個SR讓Oracle Support來進一步協助你了,當然在正式提交SR之前你有必要再次確認一下你的ASM Disk是否都滿足了以下的這些硬指標：

1.合理地設定ASM_DISKSTRING引數，若沒有設定ASM_DISKSTRING引數那麼ASM例項會嘗試到預設的一些路徑去搜尋磁碟裝置，這些預設路徑在不同作業系統上略有不同:

2.候選磁碟裝置應當屬於安裝ASM的Oracle軟體的使用者，否則使用chown或卷管理軟體修改磁碟擁有者，並保證磁碟被正確載入

3.候選磁碟裝置應當設定合理的許可權，一般為660，如果存在問題那麼可以臨時設為770以便測試

4.RAC環境中需要注意所有的磁碟裝置應當在所有節點都可見，建議使用cluvfy工具驗證