目录
问题解决过程
反思总结
oracle的rac数据库集群现在已经被广泛应用，最近在数据集市项目中将原来aix平台10g单节点数据库迁移升级至x86平台11r2rac集群数据库，为了保证数据库的高可用性和可扩展性，采用了rac的grid大集群和数据库小集群方式（例如本次问题的环境是4节点asm集群支撑2套2节点rac数据库，每个实例1台主机）。部署好第一套2节点rac数据库之后，因项目进展的需要，再添加2节点给另一个地市使用。在将grid和db集群软件、数据库都创建完成之后，同事告诉我新添加的2节点rac数据库不能用sqlplus正常启动，必须使用集群命令启动。凭着以往的经验，rac节点的数据库无论是用sqlplus还是集群命令都必须可以在任意节点进行任意顺序启动，不需要按照特定的顺序启动。
现在这套rac节点数据库还在安装阶段，还没有投入使用，因此可以进行各种各样的操作和测试。接到这个问题请求之后，首先进行测试，按照同事的说法，先启动1节点，后启动2节点，数据库可以使用sqlplus正常启动；先启动2节点，后启动1节点，发现2节点可以正常启动，1节点连nomount状态都未能进入，就报错退出。退出之后，就查看数据库的alert日志，发现在退出前报错集群无法进行通信。
根据报错信息分析，是由于集群间无法通信，导致数据库无法启动，那么根据这一点提示信息就拼命的从集群通信方面入手。因为这2个节点是后期采用添加节点的方式添加进去，第一怀疑是不是添加节点加出了问题，反复询问同事，明确回复我在添加节点时无任何的报错信息。那么就只能从使用集群命令对整个集群进行检查。使用了crsctl status resource –t ,crsctl check cluster –all,oifcfg,olsnodes,srvctl等命令进行检查，检查的结果都无异议，从中未能发现一点蛛丝马迹。
再仔细对1节点的数据库alert日志向上查看，发现有打印私网通信地址为169.254.183.196，立即查看数据库的私网通信地址发现是192.168.110.12。此时就有一个疑问，数据库alert日志中打印的私网ip地址与规划的私网ip不一致。这个时候只好外事不决问百度，问了百度之后发现是oracle在11.2.0.2.0之后添加的新特性haip。
又因为项目赶进度，所以在内部进行商讨，看看有无遇到相似或相同的案例，结果听同事说过，他们遇到过，也是相同的问题，但没有找到根本原因。后续申请协调各种资源进行分析 ，终于有了进一步的发现。发现在2节点使用sqlplus启库时，alert日志中打印的集群ip有问题，集群间通信应该使用私网，怎么使用sqplus启库打印为公网ip，这点就特别疑惑了。
172.31.0.116这个ip在此套rac数据库中定义为公网ip，那么这个问题就初步归结为2节点使用sqlplus启库会使用公网ip作为集群的通信网络。又再次对集群的公网、私网等网络进行核查和分析，并协调网络厂家、操作系统厂家进行核查，都没有发现问题。
到这里之后，几乎是山穷水尽，问题依然存在。再次百度，得到的答案是由于haip异常引起。于是分别独立启动单节点库，查看其对就的haip，发现1节点为169.254.183.196，2节点为172.31.0.116。
再次对2个节点的数据库alert日志进行对比，发现其中存在一些不同的报错信息。1节点独立启库，能够正常获取公网、私网的ip信息。2节点则提示gpnp异常，未能获取正常的私网、公网信息。后续紧接着查看gpnp的日志，发现gpnp在正常工作，未有任何的报错信息。
于是到这里，突然灵光一闪，是不是可以用trace的方法跟踪启动过程，能否从trace中分析出2节点为什么使用公网ip做为集群通信。由于是启库，只能重新启动2节点至nomount状态，然后创建pfile，在pfile中添加10046事件，然后使用pfile启动数据库至nomount状态。然后到trace目录中去查看trace文件。对trace文件打开分析，发现trace文件中提示gpnp中某个文件无法访问。
使用ls命令对文件进行查看，发现的确不存该文件，再仔细一看路径，这个路径不是grid集群的安装路径。
仔细一看这个目录，再结合操作系统为suse linux 11 sp2，初步确定为oracle用户的环境变量问题。如果对2个节点oracle的环境变量进行对比，果然不同，2节点多了2行。
看到2节点多出来的2个环境变更ora_crs_home、ora_asm_home，立即找到suse linux为oracle特意准备的环境变量文件/etc/profile.d/oracle.sh，立即将这个文件重命名，然后退出会话，重新登陆，环境变量消失。于是使用2个会话窗口，1个查看数据库alert日志，另1个使用sqlplus启库，alert日志中显示数据库正常能够获取私网、公网的ip网络，而且haip也是使用169网段的。待2节点使用sqlplus启库完成之后，再在1节点使用sqlplus启库，一切正常。然后再核查其他3个节点的/etc/profile.d/oracle.sh发现该文件要么被删除、要么被重命名。
至此为止，经过不断的折腾，这个问题终于被解决，但是回想整个解决过程，其实很冗长，也走了很多的弯路。
检查数据库alert日志，只检查出问题节点，没有立即检查未出问题节点。
未对操作系统及其对应的环境变量熟悉，其实/etc/profile.d/oracle.sh是suse专门为oracle定制的环境变量，加上这是第1次使用suse安装oracle数据库，经验不足，也是其一。
其实也曾想过是不是配置有问题，引起此次问题。在其中曾让当初部署的同事按照oracle的官方文档对操作系统配置进行一遍彻底的核查。但也未能核查出隐藏在/etc/profile.d/oracle.sh这个环境变量文件。这也正是suse为oracle定制的特色。
作者介绍：夏海雁
新炬网络公司高级技术专家，7年oracle数据库、timesten内存数据库运维管理经验。
精通oracle 10g、11g数据库管理和linux/unix系统管理。
擅长进行数据库及集群的故障诊断与系统优化，并持续专注于故障诊断技术的研究与实践。
<b></b>
<b>本文来自云栖社区合作伙伴"dbaplus"，原文发布时间：2016-01-06</b>