首先检查CRSD日志,内容如下:
(为保护客户隐私,部分内容用“XXXXX”代替)
2014-11-26 10:06:28.010: [ CRSRES][11826]32Attempting to start `ora.XXXXX.vip` on member `XXXXX`
2014-11-26 10:06:50.423: [ CRSAPP][11826]32StartResource error for ora.XXXXX.vip error code = 1
2014-11-26 10:06:50.897: [ CRSRES][11826]32Start of `ora.XXXXX.vip` on member `XXXXX` failed.
2014-11-26 10:16:51.532: [ CRSRES][11864]32startRunnable: setting CLI values
从日志内容可以看出,集群在不断尝试重启VIP资源,但是启动失败。接下来再查看故障节点的vip日志,日志目录位于$ORA_CRS_HOME/log//racg/*vip.log,日志内容如下:
(只截取关键内容)
2014-11-26 10:38:00.942: [ RACG][1] [17432678][1][ora.XXXXX.vip]: IP:192.168.222.51 is already up in the network (host=XXXXX)
IP:192.168.222.51 is already up in the network (host=XXXXX)
日志内容提示,192.168.222.51这个IP已经启动。再查看XXXXX节点的VIP配置:
srvctl config nodeapps –n XXXXX –a
发现,192.168.222.51正式XXXXX节点的vip资源对应的IP。
再查看XXXXX的网卡信息:
ifconfig –a |grep 192.168.222.51
没有输出,说明192.168.222.51并没有在XXXXX节点上启动。
进一步使用ping命令做判断:
ping 192.168.222.51
发现能正常ping通。
到此,问题已经定位,XXXXX节点的vip资源对应的IP地址被占用,导致rac集群无法启动vip资源无法启动。后来经客户调查后发现,这个IP被新安装的打印机占用了,打印机怎么能与服务器在同一网段呢?这里表示很无语。但是问题基本清晰了,用户自行将打印机的IP做调整后,VIP资源和listener资源都能正常启动。
这次的问题较为简单,因为在vip的日志中有比较明显的错误提示,但是,有些时候,资源无法启动时,在日志中找不到有用的信息,这时我们需要借助debug获取更多有用的信息。具体的操作如下:
1、使用root用户执行 crsctl debug log res "ora.dbtest2.vip:5"
2、启动nodeapps资源,srvctl start nodeapps -n dbtest2
3、关闭debug,使用root用户执行crsctl debug log res "ora.dbtest2.vip:0"
4、到$ORA_CRS_HOME/log//racg目录下查看对应资源的日志。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29821678/viewspace-1373005/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29821678/viewspace-1373005/