问题描述:3节点的Oracle 10.2.0.3版本RAC
Oracle Patch merge6平台上
主机P570,操作系统AIX 5***
没有压力状态下,拔掉节点node1的2根public网线,发现VIP重启累计用时如下:
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))
)
)
------------------------------------------------------------------------------------------------------
Oracle关于IPC协议和listener的解释很少,但是,可以看出IPC协议对VIP漂移时间的影响很大。
关于VIP的测试,中间还穿插了两段。
第一段,
拔掉节点1的2根public网线,发现节点1上的vip没有漂移至配置的节点上。当时是发现$ORACLE_CRS/srvm/auth]目录下有大量
类似"A3877132"系统用户属组的空文件。都给rm后,重新做该节点的2根public网线故障,VIP能正常漂移至指定节点。忘记原因了,只记得
还有这事情,以后难免遇到。
第二段,由于其他原因,在系统上升级Oracle patch由merge6升至merge12。
测试中发现,在merge12的平台下,节点发生2根public网线故障,vip竟然没有发生漂移,但退回到merge6正常。 当时怀疑了有2个原因:
1.merge12的补丁有bug。那这就太滑稽了,打补丁打出bug。
2.当初搭建RAC环境时,将FAIL_WHEN_DEFAULTGW_NO_FOUND由1改为0。
很快,ORACLE对merge12这个新的patch进行检查,发现代码出现问题,少了'()'引起的,修改如下:
patch的line 366,'IsIfAlive() ${_IF}'修改为' IsIfAlive ${_IF}'
再次测试,vip不漂移的问题解决。至此,一个10.2.0.3的RAC系统总共打了opatch共36个,俨然已经打成马蜂窝了。