Discover Your Missed ASM Disks

经常有网友在构建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实例会尝试到默认的一些路径去搜索磁盘设备，这些默认路径在不同操作系统上略有不同:

操作系统	默认搜索路径
Solaris	/dev/rdsk/*
Windows	\\.\orcldisk*
Linux	/dev/raw/*
Linux with ASMLIB	ORCL:*
Linux with ASMLIB	/dev/oracleasm/disks/*
HPUX	/dev/rdsk/*
HP-UX(Tru 64)	/dev/rdsk/*
AIX	/dev/*

2.候选磁盘设备应当属于安装ASM的Oracle软件的用户，否则使用chown或卷管理软件修改磁盘拥有者，并保证磁盘被正确加载 3.候选磁盘设备应当设置合理的权限，一般为660，如果存在问题那么可以临时设为770以便测试 4.RAC环境中需要注意所有的磁盘设备应当在所有节点都可见，建议使用cluvfy工具验证