1号网卡 172.18.11.51(boot)
2号网卡 172.18.12.51(standby)
service ip 172.18.11.50 (通信地址)
管理IP地址: 172.18.13.50 (两块网卡做etherchannel)
trade节点:
3号网卡 172.18.11.57(boot)
4号网卡 172.18.12.57(standby)
service ip 172.18.11.56 (通信地址)
管理IP地址: 172.18.13.56 (两块网卡做etherchannel
测试方案一:
同时停掉1,2号网卡,service ip地址漂移到4号网卡上。
此时两个两节的数据库将挂住12分钟左右。alert日志显示为一串IPC Send timeout detected. Sender ospid 200824。
最后两节点都宕掉了。
trade节点的信息为:
Thu May 24 15:35:27 2007
Errors in file /opt/oracle/admin/alisoft/bdump/trade_lmon_369608.trc:
ORA-29740: evicted by member 0, group incarnation 17
c2c节点的信息为:
Errors in file /opt/oracle/admin/alisoft/bdump/c2c_smon_512264.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-27544: Failed to map memory region for export
ORA-27300: OS system dependent operation:socket failed with status: 68
ORA-27301: OS failure message: Can't assign requested address
ORA-27302: failure occurred at: sskgxpcre1
Thu May 24 15:35:29 2007
(没有通信地址导致的)
解决办法:
在service ip地址漂移时,需要同时将该节点的db宕掉。
测试方案二:
如果停掉任一节点的hacmp的话,则service ip正常漂移,该节点上数据库当然宕掉。另一个节点正常工作。
此时再将宕掉的节点的hacmp启来,将该节点上的实例宕下来,然后才能将service ip漂移回来。
测试方案三:
将1号网卡宕掉,hacmp大约需要15秒的时间将service ip地址切到standby ip地址。一切正常。
测试方案四:
将通信地址宕掉。类似于测试方案一中的情况。因为在此种情况下service ip地址就是通信地址。
将cluster_interconnects参数设为管理口的IP地址。
再做测试:
测试方案一将只是发生service ip地址漂移,不会发生其他动作。
测试方案二,在将宕掉的hacmp启来后,数据库也可以正常启动,然后再将service ip地址漂回来。
测试方案三,以原来是一样的。
测试方案四,也是出现IPC Send timeout detected.如果在实例宕掉之前,通信恢复,则一切正常。
如果长时间不恢复,则一般情况下是拨掉网卡的实例异常宕掉。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/100091/viewspace-916304/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/100091/viewspace-916304/