天天看点

当root.sh与ORA-15031相遇

      近日处理一个Oracle Grid infrastructure(GI)安装的问题,在执行root.sh过程中失败,并显示下面错误:

1

2

3

4

5

6

7

8

9

<code>Disk </code><code>Group</code> <code>OCR creation failed </code><code>with</code> <code>the following message:</code>

<code>ORA-15018: diskgroup cannot be created</code>

<code>ORA-15031: disk specification </code><code>'/dev/vx/rdsk/dg_db01/lv_vote1'</code> <code>matches </code><code>no</code> <code>disks    &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code>

<code>ORA-15031: disk specification </code><code>'/dev/vx/rdsk/dg_db01/lv_vote2'</code> <code>matches </code><code>no</code> <code>disks</code>

<code>ORA-15031: disk specification </code><code>'/dev/vx/rdsk/dg_db01/lv_vote3'</code> <code>matches </code><code>no</code> <code>disks</code>

<code>Configuration </code><code>of</code> <code>ASM ... failed</code>

<code>see asmca logs </code><code>at</code> <code>/oracle/base/cfgtoollogs/asmca </code><code>for</code> <code>details</code>

<code>Did </code><code>not</code> <code>succssfully configure </code><code>and</code> <code>start ASM </code><code>at</code> <code>/oracle/product/11.2.0.4/grid_1/crs/install/crsconfig_lib.pm line 6468.</code>

<code>/oracle/product/11.2.0.4/grid_1/perl/bin/perl -I/oracle/product/11.2.0.4/grid_1/perl/lib -I/oracle/product/11.2.0.4/grid_1/crs/install /oracle/product/11.2.0.4/grid_1/crs/install/rootcrs.pl execution failed</code>

       错误ORA-15031的提示,还是很明显的,无法识别对应的voting磁盘,正常解决思路,就是检查磁盘是否正常挂载,权限是否正确等,需要逐项检查。在Metalink上搜索,这个错误一般都是在node2上执行root.sh会遇到,而node1都是正常的。大多是权限以及系统层面挂载出现问题。但是我这个问题,是在node1上执行root.sh就失败了。

开始各项分析检查:

1. 检查磁盘是否存在,权限是否正确,All Pass

<code>#ls -lrt /dev/vx/rdsk/dg_db01</code>

<code>crw-rw</code><code>----    1 grid     asmadmin     40,60000 Feb 12 10:51 lv_vote1</code>

<code>crw-rw</code><code>----    1 grid     asmadmin     40,60001 Feb 12 10:52 lv_vote2</code>

<code>crw-rw</code><code>----    1 grid     asmadmin     40,60002 Feb 12 10:52 lv_vote3</code>

2. 检查asm_diskstring设置

<code>SQL&gt; show parameter asm_diskstring</code>

<code>NAME</code>                                 <code>TYPE                              VALUE</code>

<code>------------------------------------ --------------------------------- ------------------------------</code>

<code>asm_diskstring                       string                            /dev/vx/rdsk/dg_db01</code>

3. 并使用kfod来查看,是否能扫描到对应的磁盘,也正常

10

11

12

13

14

15

16

<code> </code><code>kfod asm_diskstring=</code><code>'/dev/vx/rdsk/dg_db01/lv_*'</code> <code>disks=</code><code>all</code>

<code>--------------------------------------------------------------------------------</code>

<code>Disk          </code><code>Size</code> <code>Path                                     </code><code>User</code>     <code>Group</code>  

<code>================================================================================</code>

<code>  </code><code>1:     327680 Mb /dev/vx/rdsk/dg_db01/lv_data01           grid     asmadmin</code>

<code>  </code><code>2:     327680 Mb /dev/vx/rdsk/dg_db01/lv_data02           grid     asmadmin</code>

<code>  </code><code>3:     327680 Mb /dev/vx/rdsk/dg_db01/lv_data03           grid     asmadmin</code>

<code>  </code><code>4:     112910 Mb /dev/vx/rdsk/dg_db01/lv_data04           grid     asmadmin</code>

<code>  </code><code>5:       1024 Mb /dev/vx/rdsk/dg_db01/lv_vote1            grid     asmadmin</code>

<code>  </code><code>6:       1024 Mb /dev/vx/rdsk/dg_db01/lv_vote2            grid     asmadmin</code>

<code>  </code><code>7:       1024 Mb /dev/vx/rdsk/dg_db01/lv_vote3            grid     asmadmin</code>

<code>ORACLE_SID ORACLE_HOME                                                          </code>

<code>    </code><code>+ASM1 /oracle/product/11.2.0.4/grid_1                                      </code>

<code>grid@HAZZ-NRMS-RESDB01:/home/grid&gt;</code>

4. 至此,我怀疑是asm_diskstring设置的不够准确,将其更改为

<code>asm_diskstring                       string                            /dev/vx/rdsk/dg_db01/lv_*</code>

但是问题依旧没有解决,

5. 检查集群安装环境,也没有发现问题

<code>$ ./runcluvfy.sh stage -pre crsinst -n node1,node2 -verbose</code>

<code>$ ./runcluvfy.sh comp ssa -n </code><code>all</code> <code>-verbose</code>

6. 操作系统日志,没有发现错误

<code>IBM: /bin/errpt -a &gt; messages.</code><code>out</code>

       至此,可以确认,根据oracle的安装文档,目前的磁盘权限完全符合安装条件,在GI的图形化安装过程,也是可以看见ASM disk的,但是在root.sh执行过程中,就是无法通过。

       后通过Metalink查询到下面文章

ASM Is Not Detecting Raw Devices Or Regular Raw Devices On AIX (Doc ID 1174604.1)

       根据文档描述:

EMC存储,使用多路径,可能会遇到这个问题,而我的存储确实使用的EMC和多路径。

好吧,按照这个文档的Solution,测试一下

<code>Please attempt the </code><code>next</code> <code>action</code> <code>plan </code><code>on</code> <code>the mount point which </code><code>contains</code> <code>the ASM Oracle Home:</code>

<code>1) Dismount the filesystem which </code><code>contains</code> <code>the ASM Oracle Home.</code>

<code>2) Change the ownership </code><code>of</code> <code>the mount point </code><code>to</code> <code>oracle : dba</code>

<code>3) Remount the filesystem</code>

<code>4) The EMC PowerPath raw devices </code><code>or</code> <code>regular raw devices are now being discovered.</code>

我的执行步骤如下:

<code>1、dismount /u01/oracle</code>

<code>2、chown -R oracle:oinstall /u01/oracle</code>

<code>   </code><code>chmod 775 /u01/oracle</code>

<code>3、mount /u01/oracle</code>

<code>4、再次执行root.sh,成功</code>

       说真的,我很难理解,为什么mount路径的权限,会影响到ASM disk的无法识别.

        根据文档1174604.1中提及的Bug 9976459 : ASM DISK NOT GETTING DISCOVERED,其中有这样一段解释

<code>When</code> <code>a file system </code><code>is</code> <code>mounted over a directory, the permissions </code><code>of</code> <code>the root directory </code><code>of</code> <code>the mounted file system takes precedence over the permissions </code><code>of</code>  <code>the mount point.</code>

<code>A common problem </code><code>is</code> <code>failure </code><code>of</code> <code>the pwd command. Without search permission </code><code>in</code> <code>the mounted-over directory, the pwd command </code><code>returns</code> <code>the following message:</code>

<code>pwd: Permission denied</code>

<code>This problem can be avoided </code><code>by</code> <code>always setting the permissions </code><code>of</code> <code>the mounted-over directory </code><code>to</code> <code>at</code> <code>least 111.</code>

        最终,根据上面的描述,google到了IBM的解释:

http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.osdevice/mountpoint.htm

安装点

        安装点是一个目录或文件,可在该处访问新文件系统、目录或文件。要安装文件系统或目录,安装点必须为一个目录;要安装文件,那么安装点必须为文件。

       通常,文件系统、目录或文件安装在空安装点上,但这不是必需的。如果作为安装点的文件或目录包含任何数据,那么另一个文件或目录在该安装点进行安装时,该数据不可访问。实际上,已安装的文件或目录覆盖了以前在该目录中的内容。一旦撤销在初始目录或文件上的安装,该目录或文件就重新可访问。

       在目录上安装文件系统时,已安装文件系统的根目录许可权优先于安装点的许可权。有一个例外是安装目录中的 ..(点点)父目录条目。为了操作系统能够访问新文件系统,安装点父目录信息必须可用。

      例如,如果当前工作目录是 /home/frank,那么命令 cd .. 将工作目录更改至 /home。 如果 /home/frank 目录是已安装的文件系统的根,那么为了使 cd .. 命令成功,操作系统必须在 /home/frank 目录中找到父目录信息。

      对于需要父目录信息才能成功的任何命令,用户必须具有在安装目录中的搜索许可权。授予对安装目录的搜索许可权失败可能会导致不可预测的结果,尤其是因为安装目录许可权是不可见的。常见问题是 pwd 命令失败。如果没有对安装目录的搜索许可权,pwd 命令将返回此消息:

pwd:许可权被拒绝

通过始终将安装目录的许可权至少设置为 111 可避免此问题。

至此,问题已经解决,由于mount点的权限问题,会导致ASM disk识别的失败。

哎!!!神奇的经历!!!

本文转自 hsbxxl 51CTO博客,原文链接:http://blog.51cto.com/hsbxxl/1614579,如需转载请自行联系原作者