關於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。。呵呵
特此記錄。睡覺！