Sun Apr 29 03:42:00 BEIST 2012
Process OS id : 1151516 alive after kill
Errors in file/oracle/product/10.2.0/admin/xxxxdb/udump/xxxxdb2_ora_110596.trc
Immediate Kill Session#: 1668, Serial#: 2
Immediate Kill Session: sess:700000383763638 OS pid: 693786
Sun Apr 29 03:42:01 BEIST 2012
Process OS id : 693786 alive after kill
Errors in file/oracle/product/10.2.0/admin/xxxxdb/udump/xxxxdb2_ora_110596.trc
Immediate Kill Session#: 1669, Serial#: 2
Immediate Kill Session: sess:70000038275d1f8 OS pid: 1292056
6
― 说明：故障期间，节点二上数据库的Service被OFFLINE，这一点正常。但随后CRS
将连接到节点二上的所有客户端连接都强行Kill掉了。该问题和Oracle Bug 6955040有
关。
五、分析RACGVIP
由于问题原因定位到 VIP资源异常上，而VIP切换到节点一上是正常的，
因此极有可能是由于VIP检查的时候出现异常导致CRS 将VIP OFFLINE。由于
Oracle CRS在进行VIP检测的时候是通过RACGVIP这个 SHELL脚本实现功能
的，因此我们分析和测试了RACGVIP脚本。
我们注意到其中一段脚本，如下：
#Check the status of the interface thro' pinging gateway
if[ -n "$DEFAULTGW" ]
then
_RET=1
#get base IP address of the interface
tmpIP=`$LSATTR -El ${_IF} -a netaddr | $AWK '{print $2}'`
#get RX packets numbers
_O1=`$NETSTAT -n -I $_IF | $AWK "{ if (/^$_IF/) {print \\$5;exit}}"`
x=$CHECK_TIMES
while [ $x -gt 0 ]
do
if [ -n "$tmpIP" ]
then
$PING -S $tmpIP $PING_TIMEOUT $DEFAULTGW > /dev/null 2>&1
else
$PING $PING_TIMEOUT $DEFAULTGW > /dev/null 2>&1
fi
_O2=`$NETSTAT -n -I $_IF | $AWK "{ if (/^$_IF/) {print \\$5;exit}}"`
if [ "$_O1" != "$_O2" ]
then
# RX packets numbers changed
_RET=0
break
fi
$SLEEP 1
x=`$EXPR $x - 1`
done
if [ $_RET -ne 0 ]
then
logx "checkIf: RX packets checked if=$_IF failed"
else
logx "checkIf: RX packets checked if=$_IF OK"
fi
else
logx "checkIf: Default gateway is not defined(host=$HOSTNAME)"
if [ $FAIL_WHEN_DEFAULTGW_NO_FOUND -eq 1 ]
then
_RET=1
else
_RET=0
fi
fi
― 说明：这段脚本说明，CRS在做VIP check的时候机制如下，定期向缺省网关（Default
Gateway）发包，如果发包前后检测到网卡上有包流量（output值前后不一样）则说
明检测网络正常，VIP check通过。发包的操作通过AIX 命令执行，还原所有变量后的
命令如下
― ping ?S xxx.xxx.xxx.2 ?c 1?w 1 xxx.xxx.xxx.254
― 参数含义如下：
-S hostname/IP addr
Uses the IP address as the source addressin outgoing ping packets.
-c Count
Specifies the number of echo requests, asindicated by the Count
variable, to be sent (and received).
-w timeout
This option works only with the -c option.It causes ping to wait
for a maximum of 'timeout' seconds for areply (after sending the
last packet).
― PING_TIMEOUT参数控制了-c 和-w的值，RACGVIP 脚本中设置如下：
# timeout of ping in number of loops
PING_TIMEOUT=" -c 1 -w 1"
― 我们检查了10.2.0.3版本下的设置，发现在10.2.0.3版本下，PING_TIMEOUT参数设置
为如下值：
# timeout of ping in number of loops
PING_TIMEOUT=" -c 1 -w 3"
― 当前PING_TIMEOUT的设置意味着如果在pingdefault gateway 的1秒内没有成功向
外发送出一个包，那么CRS会经过一次SLEEP后再次尝试ping操作，如果还是没有成
功，CRS即宣布网络异常，VIP OFFLINE。
结论
Oracle 10.2.0.5在RACGVIP脚本上的细微改变说明，Oracle认为10.2.0.5版本
下对网络性能及稳定性更高了。但是将PING_TIMEOUT 由1秒更改为3秒，会大
大增加CRS 的敏感度，使得细微的网络异常即会造成CRS 中的 VIP检测失败。
根据上述分析，我们认为节点二故障原因如下：
1、 升级到10.2.0.5后，CRS 对网络延时更加敏感
2、 在4月29 日凌晨3点故障期间，网络出现了及其短暂的延时导致VIP检测
失败，CRS 将VIP以及依赖于VIP的资源OFFLINE。
3、 CRS 在OFFLINE数据库服务的时候命中Bug6955040造成客户端连接被
全部杀光。
故障重现
我方在生产环境模拟了这一段异常情况：
步骤流程
1 打开CRS VIPdebug
2
节点二上找出VIP（xxx.xxx.xxx.4 ）使用的网络设备（en10）
以及对应的ServiceIP（xxx.xxx.xxx.2 ）
3 交换机上找出对应的端口
4 Block该端口一小段时间
5 观察CRS 和数据库日志
我方我们观察到其中 CRS 日志和数据库日志信息和故障期间完全一致，这
充分证明了前面的判断。
同时，VIP的debug 信息显示如下内容，我们可以从中清晰的看到，由于
网络问题导致发包失败后，CRS 立即将VIP置于 OFFLINE状态：
2012-05-01 20:36:22.560: [ RACG][1] [1291828][1