一次关于VIP漂移问题的测试。如果仅仅是参数可控就好办了，不要轻易相信任何人。

问题描述：
3个节点的Oracle 10.2.0.3版本RAC
Oracle Patch merge6平台上
没有压力状态下，拔掉节点node1的2根public网线，发现
CRS check node1.vip error 9s
CRS stop node1.vip 10s
CRS stop node1.lis 85s
CRS start node1.vip on node3 89s

节点故障时VIP漂移时间超过90s，对于实时应用是可怕的。

一开始想到调整CRS服务关于VIP故障的check参数CHECK_INTERVAL及SCRIPT_TIMEOUT，由默认的60s减少到20s或许能改善VIP的切换时间。
修改参数的命令如下：
# srvctl stop instance -d dbserver3 -i zc3
# cd $ORA_CRS_HOME/bin
# ./crs_stat -p ora.dbserver3.vip > /tmp/ora.dbserver3.vip.cap
# ./crs_profile -update ora.dbserver3.vip -dir /tmp -o ci=20,st=20
# ./crs_register ora.dbserver3.vip -dir /tmp -u
检查CHECK_INTERVAL及SCRIPT_TIMEOUT的命令如下：
$./crs_stat -p ora.dbserver3.vip | grep CHECK_INTERVAL
CHECK_INTERVAL=20
$./crs_stat -p ora.dbserver3.vip | grep SCRIPT_TIMEOUT
SCRIPT_TIMEOUT=20
但是修改后测试发现，虽然改小了CRS的check周期，但是VIP的漂移时间仍然超过80s，问题显然与CRS无关。

后检查listener.ora的配置，发现没有添加IPC协议，添加IPC协议 as first entry。再次测试VIP漂移时间在15s以内。修改如下：
LISTENER_DBSERVER3 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
(ADDRESS = (PROTOCOL = TCP)(HOST = node_vip)(PORT = 1521)(IP = FIRST))
(ADDRESS = (PROTOCOL = TCP)(HOST = node_ip)(PORT = 1521)(IP = FIRST))
)
)

查资料，关于listener.ora中IPC协议的解释很少，不知哪位大拿可以解惑？万分感谢！但是，可以看出IPC协议对VIP漂移时间的影响还是很大的。

后续：
关于VIP的测试，中间还穿插了一段。由于其他原因，在系统上由升级Opatch由merge6升至merge12。
测试中发现，在merge12的平台下，节点发生2根public网线故障，vip竟然没有发生漂移，但退回到merge6正常。
当时怀疑了有2个原因：
1.merge12的补丁有bug。那这就太滑稽了，打补丁打出bug。
2.ORACLE工程师当初搭建RAC环境时，将FAIL_WHEN_DEFAULTGW_NO_FOUND由1改为0。貌似是itpub的ORACLE版主干的。

很快，ORACLE对merge12这个新的patch进行检查，发现代码出现问题，少了'()'引起的，修改如下：
patch的line 366，'IsIfAlive() ${_IF}'修改为' IsIfAlive ${_IF}'

再次测试，vip不漂移的问题解决。至此，一个10.2.0.3的RAC系统总共打了opatch共36个，俨然已经打成马蜂窝了。