关于RAC的io fence,一直想写点什么作为总结，毕竟干了这么多年，遇见的大大小小的节点重启也很多次了，今天，月黑风高，LOL被人骂成翔，还是静下心来写写技术文档吧
RAC的io fence,中文名IO隔离，当RAC节点间无法正常联系彼此的时候，为了保证数据完整性，ORACLE会对故障节点发起驱逐命令，驱逐命令在原理上就是通过voting disk发出killblock，使节点重启或蓝屏，避免故障节点有权限继续对数据进行读写造成的讹误。这个很好理解嘛，两地分居的恋人，电话不通，邮件不通，更不能见面嘿秋，肯定GG哇。RAC 的IO FENCE表现形式，WINDOWS为蓝屏，AIX，LINUX，HPUX为reboot.
那么，什么情况下会触发IO FENCE哩？我个人总结了以下几种情况。浅薄经验，欢迎拍砖！
1.内联网络丢失
这种是最最最常见的情况，内联网络在RAC中负责最重要的cache fusion部分，但是一部分同学喜欢在生产环境给他玩双绞线直连，对。你没看错，就是网线直连，记住，这种情况 是最最最不允许的。请使用独立交换机或ＶＬＡＮ组成ＲＡＣ的内联网络。
ＯＫ，闲话不多说，我们来看看内联网络联通失败导致的一系列经过。
当节点间网络通讯失败，ＯＲＡＣＬＥ的network monitor首先通过votemsg及NETMSG确定节点间互通情况，将cluster分为small cluster与large cluster,
保证large cluster的正常运行，剔除其他节点。在超过2节点的情况下，会按照通过VOTE及残余网络侦测到的信息，构建两个subcluster,保留节点数多的那一个。
在2节点环境中，当使用交换机作为内联媒介的时候，如果两节点内联通讯中断，优先保留低位节点。
RAC internal中有以下一段
. When interconnect breaks – keeps the largest cluster possible up, other nodes will be evicted, in 2 node cluster lowest number node remains.
Node eviction: pick a cluster node as victim to reboot.Always keep the largest cluster possible up, evicted other nodes two nodes: keep the lowest number node up and evict other.it is always the node2 that is evicted.
内联网络丢失在ocssd中的表现为
CSSD]2011-04-23 17:11:53.054 [3053439888] >WARNING: clssnmPollingThread: node vrh1 (1) at 50 8.910601e-269artbeat fatal, eviction in 29.800 seconds
[ CSSD]2011-04-23 17:11:53.054 [3053439888] >TRACE: clssnmPollingThread: node vrh1 (1) is impending reconfig, flag 1037, misstime 30200
[ CSSD]2011-04-23 17:11:53.054 [3053439888] >TRACE: clssnmPollingThread: diskTimeout set to (57000)ms impending reconfig status(1)
[ CSSD]2011-04-23 17:11:54.516 [3053439888] >WARNING: clssnmPollingThread: node vrh1 (1) at 50 8.910601e-269artbeat fatal, eviction in 28.790 seconds
[ CSSD]2011-04-23 17:12:14.826 [3053439888] >WARNING: clssnmPollingThread: node vrh1 (1) at 75 8.910601e-269artbeat fatal, eviction in 14.800 seconds
[ CSSD]2011-04-23 17:12:16.265 [3053439888] >WARNING: clssnmPollingThread: node vrh1 (1) at 75 8.910601e-269artbeat fatal, eviction in 13.800 seconds
[ CSSD]2011-04-23 17:12:27.755 [3053439888] >WARNING: clssnmPollingThread: node vrh1 (1) at 90 8.910601e-269artbeat fatal, eviction in 5.800 seconds
[ CSSD]2011-04-23 17:12:29.197 [3053439888] >WARNING: clssnmPollingThread: node vrh1 (1) at 90 8.910601e-269artbeat fatal, eviction in 4.800 seconds
[ CSSD]2011-04-23 17:12:30.658 [3053439888] >WARNING: clssnmPollingThread: node vrh1 (1) at 90 8.910601e-269artbeat fatal, eviction in 3.800 seconds
[ CSSD]2011-04-23 17:12:32.133 [3053439888] >WARNING: clssnmPollingThread: node vrh1 (1) at 90 8.910601e-269artbeat fatal, eviction in 2.800 seconds
[ CSSD]2011-04-23 17:12:33.602 [3053439888] >WARNING: clssnmPollingThread: node vrh1 (1) at 90 8.910601e-269artbeat fatal, eviction in 1.790 seconds
当然不是说看见这个就直接判定是内联网络通讯中断，也有可能是节点压力过大导致。
在我遇到的内联网络通讯中断的情况中，一般分为以下几种
1.内联交换机故障，这个没什么好说的。。。悲剧哇
2.做了聚合的内联网卡硬件故障。这个在AIX平台很悲剧，因为由于AIX平台etherchannel的网卡切换时间较长，所以还是会发生驱逐的。
3.内联网络使用的交换机上有病毒。。这个这个是最悲剧的，所以各位巡检的时候请注意是否有WIN的机器，这个攻击可以是垮VLAN。
2. VOTING DISK 丢失
10G开始后，ORACLE在RAC中使用VOTINGDISK交换磁盘心跳信息，因此为保证节点间传输的正确，需保证每套RAC拥有2N+1的VOTING DISK，每个节点可以访问的
VOTING DISK必须是所有voting disk的50%以上，比如一套RAC使用常规的3个VOTING DISK，那每个节点必须可以访问到超过2个，否则，节点将会保护性重启
那我们可不可以配置偶数个VOTING DISK，可以啊，但是没意义，试想假如我们配置了4个，half也是要两个。
如果丢失未超过half,那么ORACLE会在ocssd.log中记录，但是不影响运行。丢失超过half，恭喜，节点自我保护重启。
3.节点heavy.
当节点正在经历高CPU运算的时候，系统因为CPU繁忙，无法获取CPU时间片发出心跳MSG（网络和磁盘心跳），这时节点处于假死状态，其他节点发现该节点失去
响应，于是直接reboot繁忙节点。（哼，敢不接老娘电话，赐一丈红！）
确定条件：AWR以及故障时点的v$active_session_history
4.NTP或其它时间引起的故障
大多生产环境都有NTP时钟服务器，如时钟服务器发生故障或异常，节点会固定时长的重启，这个比较妖异，没有任何的LOG显示，直接REBOOT，如果是AIX的
平台，ERRPT中会提示mini dump,这个可以作为判断的一个方面。
5.内存耗尽或进程超限引发的进程无法正常spawn,导致节点reboot
这个在alert日志里都有很明显的显示，例如
Thu Nov 27 11:51:54 2014
Errors in file /oracle/admin/crmii/bdump/crmii_psp0_5308592.trc:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
如果你是AIX平台，那有可能在errpt里面看见mini dump信息，这个时候就要具体信息具体对待了。不是所有的mini dump都是NTP。。呵呵
特此记录。睡觉！