一次ORA-15055 ORA-12547 RAC中一个节点不能识别asm磁盘解决办法

环境是在AIX6.1上安装的oracle11.2.0的RAC。

只是在rac1上运行dbca建库的时候，发现rac1上发现不了asm磁盘组。

首先检查磁盘组挂载情况

su - grid        #进入grid用户环境

sqlplus / as sysasm       #连接到asm实例

select name,state from v$asm_diskgroup    #检查磁盘组挂载情况，也正常

于是，我切换到rac2上运行dbca，rac2上可以发现asm磁盘。

之后检查权限问题

ls -l /dev/rhdisk*

crw-------    2 root     system       13,  2 Jan 20 12:00 /dev/rhdisk0

crw-rw----    1 grid     asmadmin     13,  3 Feb 20 19:00 /dev/rhdisk1

crw-rw----    1 grid     asmadmin     13,  1 Feb 20 19:04 /dev/rhdisk2

crw-rw----    1 grid     asmadmin     13,  4 Feb 20 19:00 /dev/rhdisk3

没问题，检查用户权限

lsuser  oracle

oracle id=502 pgrp=oinstall groups=oinstall,dba,oper,asmdba home=/home/oracle shell=/usr/bin/ksh

oracle用户已经属于asmdba组，此处oracle用户必须属于asmdba组才能拥有asm磁盘的管理权限。

然后我就想，asm实例要被rdbms实例使用，那么

两个实例之间通信的接口是什么？

于是，我又看了《数据库体系结构和ASM》http://www.tup.tsinghua.edu.cn/Resource/tsyz/030221-01.doc，终于搞清楚了，使用了asm实例的rdbms实例比一般实例多了两个进程，分别是rbal和asmb.其中第一个进程是是用来自动调整数据在asm磁盘中各个磁盘间的平衡问题，bal即balance。如果asm磁盘组中增加或删除了磁盘，则原来的数据会自动根据原本设置的参数进行平衡分布。第二个进程就是负责两个实例之间通信的。

于是，赶紧检查这个进程

ps -ef |grep ora

确实发现了这个进程

oracle 15532250        1   0 19:18:08      -  0:00    oracle+ASM2_asmb_db1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

这个实例是我在rac2上执行dbca建立的。

之后，我

查看了trace中的alert_db1.log

在其中发现了这样的信息。

ORA-15055: unable to connect to ASM instance

ORA-12547: TNS:lost contact

有了错误代码，赶紧百谷，很显然这是个很大众的问题，没费力气就找到解决方案了。

是因为$ORACLE_HOME/bin/oracle文件夹的权限不对，正确的设置应该是

$ORALCE_HOME/bin/oracle目录和$GRID_HOME/bin/oracle目录两个目录的权限信息都是6751

想想我在安装RAC的时候，确实因为创建默认目录没建好于是一股脑的修改过权限。

chmod  6751  /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle

之后检查一下

ls -l /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle

-rwsr-s--x    1 oracle   asmadmin  271802998 Jan 22 10:12  /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle

ls -l /u01/app/11.2.0/grid/bin/oracle

-rwsr-s--x    1 grid     oinstall  237879872 Jan 21 17:20  /u01/app/11.2.0/grid/bin/oracle

修改完权限后，在rac1上执行dbca可以顺利发现磁盘组。

总结

但是，我在修正问题的过程中，发现连不上asm磁盘组的问题并不一定就是因为6751造成的，比如这个

http://blog.itpub.net/9399028/viewspace-773919

只是我没遇到这种情况而已。而前面我因为没有立刻想到先查看日志，于是检查这个检查那个，还看了几十页的介绍asm的文档。可以说走了好多弯路，虽然走弯路的过程中见识了不少，但弯路就是弯路。

所以，以后遇到这种情况，首先第一部就是查看日志文件，然后对症下药，检查各个资源的状态，最后解决问题。

 

附上官方的解释：

   The issue is caused by incorrect permissions of GI_HOME/bin/oracle and ORACLE_HOME/bin/oracle, which lead to connections failed from an RDBMS instance (RDBMS) to the ASM instance.

   For this customer, the ASM instance works fine and the DG have been mounted, the permissions of GI_HOME/bin/oracle and ORACLE_HOME/bin/oracle are incorrect.

   If the permissions are incorrect, this will lead to connections failed from an RDBMS instance (RDBMS) to the ASM instance.$ORACLE_HOME/bin/oracle is the main Oracle RDBMS kernel binary, and implements the functions of all background daemons: PMON, SMON, DBWR, LGWR, CKPT, etc.

   Connection functionality implies attach to SGA shared memory, which needs to be initialized at instance startup; this happens with routines inside bin/oracle and (at a very high level) user privileges of who starts up the instance need to match with user privileges of who wants to connect to the instance.

   Database open implies opening files; this also happens in code inside bin/oracle. Again, privileges of who starts up the instance and attempts to open the database need to match the privileges of files where the data actually resides.ASM is implemented as an Oracle instance - starting out of the bin/oracle in GI_HOME; so you'll also have connections from an ORACLE_HOME instance (RDBMS) and a GI_HOME instance (ASM) for I/O path translations.

来源：http://space.itpub.net/22664653/viewspace-706623