转自(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实例会尝试到默认的一些路径去搜索磁盘设备,这些默认路径在不同操作系统上略有不同:
操作系统 | 默认搜索路径 |
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工具验证
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14359/viewspace-722831/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14359/viewspace-722831/