略记下RAC集群中的一些解决问题的小经验,报错的图片未截图放置此处,相信碰到此问题的朋友,对于文中的错误也有认识,因此省略截图,而此文备用节点指的是node2,而主节点是node1。
当装完ORACLE数据库软件后(未装数据库),然后安装数据库ASM实例时,挂载共享分区设备的关键步骤时,会出现类似其他节点无法连接,找不到其他节点的监听程序,不能在其他节点上正常挂载磁盘分区类似的错误。一般显示的结果只有主节点才能正常挂载共享分区设备,如果强制进行后续建库操作,则会造成在备用节点上,无法启动数据库实例,RAC建库自然是失败的。
按照我自己在电脑上的尝试办法,解决途径如下:假设为双节(node1为主节点,node2为备用节点)的RAC。
此时查看两个节点的lsnrctl监听程序有无正常运行,按照我所遇到的情况,一般是node1正常开启,node2启动失败,也无法强制开启
node1$ lsnrctl status
node2$ lsnrctl status
查看双方节点的集群同步进程运行状态,我所遇到的情况是全部启动(包括每个节点的监听程序)即为ONLINE状态。
node1$ cd /u01/app/oracle/product/10.2.0/crs_1/bin
node1$ ./crs_stat -t
node2$ cd /u01/app/oracle/product/10.2.0/crs_1/bin
node2$ ./crs_stat -t
如果是包括监听等程序在内的许多进程是OFFLINE状态,那可以利用如下命令启动相关进程,然后尝试启动lsnrctl进程,不过我觉得这个一般是无用功……没怎么尝试成功,因为我把之前的集群软件,数据库软件,监听程序等环境都配置完成,使得所有进程保持了ONLINE状态,才能完成后续的RAC集群实验。
node_$ ./crs_start -f offline的相关进程名 将相关进程启动到ONLINE状态
相关环境的信息检查基本获知,解决问题的方法如下,相关命令需要在每个节点按序运行。
node1# cd /u01/app/oracle/product/10.2.0/crs_1/bin
node1# ./crsctl stop crs
node2# cd /u01/app/oracle/product/10.2.0/crs_1/bin
node2# ./crsctl stop crs
node1$ lsnrctl start
node1$ lsnrctl status
node2$ lsnrctl start
node2$ lsnrctl status
node1# ./crsctl start crs
node2# ./crsctl start crs
node1# watch -n 5 './crsctl check crs'
node2$ cd /u01/app/oracle/product/10.2.0/crs_1/bin
node2$ ./crs_stat -t
命令说明:先在各个节点以root用户关闭crs服务,然后在各个节点以oracle用户开启lsnrctl监听服务,查看监听服务lsnrctl是否正常开启,一般我做实验时,通过这个步骤便可以开启每个节点的lsnrctl服务了,接着在每个节点继续在同路径下,开启crs服务。然后以watch命令,查看crs服务开启状态,直到显示‘……healthy’等信息,便知crs服务已经开启了。最后回到节点任意节点,执行命令 crs_stat -t 检查到进程是否都运行到ONLINE状态。
则可以重新安装数据库实例,因此之前已经有ASM实例存在系统中,因此在重新运行dbca命令时,则不要选择 ‘create database’选项,选择‘configure……’等字样的选项,具体名称我不记得了。然后输入之前按照实例时配置的口令,则就可以看到之前配置的共享设备信息,尝试‘mount all’选项,则可以在所有节点上挂起所有的共享设备,进行正常的装库操作了。
具体的操作到哪一步,点击哪些按钮,我没有配图,只是粗略描述下,因为主要的解决命令,已经敲出了。这儿只是相关问题的粗略总结,等自己知识足够了,然后总结起来,给予共享,此日志先暂存空间中。
备注:因为我只是在自己的机器上进行实验,因为一次安装RAC时间开销,于我来说,因为硬件问题,需要至少5个小时才能完成。所以没有推倒实验进行多次尝试,只是当别人出现此问题时,我也循着自己的小经验,按照以上步骤,将其顺利解决,问题的终究产生原因,以及为何如此解决我也只是多次尝试胡乱而得,并非从原理上所得,因此可能说法比较偏颇了,希望别人可以指出。