AIX 修改PUBLIC 网卡子网掩码导致RAC的 VIP/SCAN IP/数据库监听无法启动故障处理

环境说明

OS操作系统:AIX

数据库版 本:ORACLE 11.2.0.4 双节点 RAC

 

故障问题描述

    2016418日接到客户电话描述 RAC VIP SCAN IP 和数据库监听没启动。

经过分析诊断是服务器 PUBLIC 接口网卡修改了子网掩码后与VIP SCAN IP 的子网掩码不一

致导致 VIPSCAN IP 和数据库监听无法启动。

 

故障分析

 

1、查看GRID 日志没发现有价值的日志

2、此时脑海中没有思路不知道要看什么日志查找问题原因

2.1 使用 crsctl status resource -t 查看资源状态,发现网络资源、VIPSCAN IP和监听都没启动

 

2.2 使用 ifconfig -a 查看没有VIP SCAN IP IP 地址

 

由于没有思路2.12.2 重复执行多次浪费了一个小时。

 

2.2 此时没有思路,不知道看什么日志查找故障原因,于是决定重启集群,再GRID 日志没发现有用的日志(这一步做的无用工)

 

# root 用户执行

/oracle/grid/bin/crsctl stop  cluster

 

# 在启动集群的命令行输出信息和GRID日志中没发现有用的信息

/oracle/grid/bin/crsctl stop  cluster

 

# 同时使用 tail -f  查看GRID 日志

 

3、由于前面的步骤都没找到有用的信息,于是决定使用SRVCTL 是否能启动网络资源,看到命令行输出的信息后,脑海中突然灵光一闪使用错误信息在网上搜索说不定能找到解决办法。

使用GRID 用户执行下面的命令

srvctl start nodeapps -n node2

 

PRCR-1013 : Failed to start resource ora.net1.network

PRCR-1064 : Failed to start resource ora.net1.network on node nedo2

CRS-2674: Start of 'ora.net1.network' on 'node2' failed

PRCR-1079 : Failed to start resource ora.node2.vip

CRS-2674: Start of 'ora.net1.network' on 'node2' failed

CRS-2674: Start of 'ora.net1.network' on 'node1' failed

CRS-2632: There are no more servers to try to place resource 'ora.node2.vip' on that would satisfy its placement policy

PRCR-1013 : Failed to start resource ora.ons

PRCR-1064 : Failed to start resource ora.ons on node node2

CRS-2674: Start of 'ora.net1.network' on 'node2' failed

 

3.1 在百度使用  PRCR-1013 : Failed to start resource ora.net1.network 搜索,找到一篇文章描述

    PUBLIC 接口网卡的子网掩码与OCR 中记录的子网掩码不一致导致 VIPSCAN IP 和数据库监听无

    法启动。该文章引用 MOS 文档 1270186.1

 

3.2 使用 PRCR-1013 : Failed to start resource ora.net1.network MOS 也找到了文档 1270186.1

2. CRSD 告警日志提示错误

2016-04-18 03:50:59.032: [UiServer][11311]{1:26654:176} Container [ Name: ORDER

     MESSAGE:

     TextMessage[CRS-2545: Cannot operate on 'ora.LISTENER_SCAN1.lsnr'. It is locked by 'SYSTEM' for command 'Resource Autostart : node1 node2']

     MSGTYPE:

     TextMessage[1]

     OBJID:

     TextMessage[ora.LISTENER_SCAN1.lsnr]

     WAIT:

     TextMessage[0]

]

2016-04-18 03:50:59.032: [ COMMCRS][11311]clscsendx: (112d65a90) Connection not active

 

2016-04-18 03:50:59.032: [UiServer][11311]{1:26654:176} CS(112d65190)Error sending msg over socket.6

2016-04-18 03:50:59.072: [UiServer][11311]{1:26654:176} Communication exception sending reply back to client.FatalCommsException : Failed to send response to client.

(File: clsMessageStream.cpp, line: 275

 

2016-04-18 03:50:59.073: [UiServer][11311]{1:26654:176} Container [ Name: UI_DATA

     ora.LISTENER_SCAN1.lsnr:

     TextMessage[233]

]

2016-04-18 03:50:59.073: [UiServer][11311]{1:26654:176} CS(112d65190)No connection to client.6

2016-04-18 03:50:59.073: [UiServer][11311]{1:26654:176} Communication exception sending reply back to client.FatalCommsException : Failed to send response to client.

(File: clsMessageStream.cpp, line: 275

 

2016-04-18 03:50:59.073: [UiServer][11311]{1:26654:176} Done for ctx=1123e1510

2016-04-18 03:50:59.074: [UiServer][11311]{1:26654:177} Container [ Name: ORDER

     MESSAGE:

     TextMessage[CRS-2545: Cannot operate on 'instance of ora.LISTENER.lsnr assigned to node1'. It is locked by 'SYSTEM' for command 'Resource Autostart : node1 node2']

     MSGTYPE:

     TextMessage[1]

     OBJID:

     TextMessage[ora.LISTENER.lsnr node1 1]

     WAIT:

     TextMessage[0]

]

 

 

3、:检查VIPSCAN IP 的子网掩码:

node2@[/oracle/grid/log/szdevl02]>srvctl config nodeapps -a

Network exists: 1/172.16.10.192/255.255.255.224/en1, type static

VIP exists: /szdevl01-vip/172.16.10.214/172.16.10.192/255.255.255.224/en1, hosting node node1

VIP exists: /szdevl02-vip/172.16.10.215/172.16.10.192/255.255.255.224/en1, hosting node node2

 

VIPSCAN IP 的子网掩码是 255.255.255.224,操作系统的子网掩码是 255.255.255.240,由此确定导致VIP SCAN IP 和数据库监听无法启动的原因是 PUBLIC 接口网卡的子网掩码与OCR中配置的VIP SCAN IP 的子网掩码不一致。

1)    

4、修改 VIP 的子网掩码与PUBLIC 接口网卡子网掩码一致:

/oracle/grid/bin/srvctl modify nodeapps -n node2 -A 172.16.10.215/255.255.255.240/en1

 

 

#启动GRID 的网络资源

srvctl start nodeapps

 

 

 

总结:

1. 在没有思路的情况下重复执行步骤12浪费了一个小时,以后处理故障一定要想好思路

   再动手。如果在动手收集信息时发现思路是错的,就要调整好思路再动手,切忌在没思路

   的情况下,盲目操作。

2. 在处理RAC 故障时,如果 GRID 日志中没有有价值的信息,可以使用 crsct status

   resource  -t 查看是什么资源有问题,然后再使用单独启动该资源的命令来启动该资源,

   注意看命令行的输出信息(特别是命令行输出的错误信息)。比如在这次故障处理中我们

   通过 srvctl start nodeapps -n node1 启动网络资源、VIPSCAN IP 和监听,使用命令行输出的

    错误信息在百度和MOS 搜索找到了解决办法。

3. 如果 GRID 日志中没有有价值的信息,可以查看下列日志寻找有价值的信息:

   $GRID_HOME/cfgtoollogs/crsconfig/rootcrs_$HOST.log

   $GRID_HOME/log/$HOST/ohasd/ohasd.log

   $GRID_HOME/log/$HOST/crsd/crsd.log

   alert_+ASM1.log on first node:

   alert_+ASMn.log on other nodes:

   $GRID_HOME/log//agent 目录下的日志

   $GRID_HOME/log//cssd 目录下的日志

  $GRID_HOME/log//evmd 目录下的日志









请使用浏览器的分享功能分享到微信等