RAC資料庫只能啟動一個節點的故障

這個月實在是太忙了，幾乎每天都是7點多起床，然後去客戶現場，然後加班，回來就覺得累的不行啦！

所以一直沒有更新，算是給自己找個藉口吧～～

其實需要總結的東西還是挺多的，直到放假的最後一天晚上，我總算有心想去總結下了～！

先要總結的就是月初解決過的一個故障（其實算是未遂），現場描述如下：

雙節點RAC資料庫，只能啟動一個節點，無論哪個節點先啟動，另外一個節點就無法正常啟動了！系統平臺是AIX5L，使用hacmp 5管理共享磁碟，無法啟動的表現就是可以mount，alter database open就hang在那不動，沒有任何報錯資訊，只有後臺程式QMNC程式無法啟動，重新啟動的資訊，還有MMNL absent for 1474 secs; Foregrounds taking over的資訊給出，查了些關於這兩個程式的說明，都是因為資料庫無法正常啟動，所以有的正常反應！不能作為解決問題的根源和依據。

出現該問題前，客戶進行了一下資料轉換的操作，中間等待長時間無反應，所以最後選擇重啟資料庫，然後hang住很長時間，然後shutdown abort關閉資料庫，然後再啟動就出現上述問題！

到達現場，開始嘗試啟動無法啟動的資料庫，發現就是hang在alter database open的過程，如果不做任何操作，就一直hang在這個過程不動，觀察系統負載，沒有任何變動，如果這時候關閉第一個啟動的節點，第二個啟動的節點就能完成正常啟動。這個過程資料庫中在做什麼呢？

判斷來判斷去，在metalink中也搜尋半天，發現有個兩個bug可能導致這個問題，但是打相應patch後依然如故！兩個patch分別為p5106909和p5190596，感興趣可以去參考下！

分析從故障開始的日誌，發現在alert日誌中有Waiting for clusterware split-brain resolution，中文就是腦裂，懷疑網路存在問題，但是使用ping命令ping心跳地址，正常！！！

系統中errpt有：

4507DE58   0507180209 I H ent2           ETHERNET NETWORK RECOVERY MODE
DED8E752   0507180209 T H ent2           ETHERNET DOWN
4507DE58   0507180209 I H ent5          ETHERNET NETWORK RECOVERY MODE
DED8E752   0507180209 T H ent5           ETHERNET DOWN
系統工程師說是網路卡模式問題，應該沒什麼影響！（我就相信了據說是IBM的工程師，結果後來……唉！）

所以下面我就又開始折騰這個資料庫啊，各種方法嘗試，折騰一天，沒有什麼眉目，回去休息，明天繼續吧！

結果第二天一來，客戶就告訴我，應用的工程師，把兩個資料庫節點都給起來了，方法就是：啟動第二個節點的時候，在第一個節點執行命令：alter system flush buffer_cache;就是清空第一個啟動節點的buffer cache，然後第二個節點就能正常啟動了！不知道他是怎麼想到的，但是這就說明，其實第二個節點啟動時候hang在了同步buffer cache的過程了，清除了第一個節點buffer cache就好了！具體猜想應該是資料字典！

雖然是都啟動了，但是這種方式絕對不是解決辦法，因為如果再有需要同步cache的操作，資料庫還是會出現問題，結果執行了大約1個多小時，資料庫果然出現問題：又出現腦裂，日誌如下：

Thu May  7 09:19:11 2009
IPC Send timeout detected. Receiver ospid 160682
Thu May  7 09:19:11 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lms0_160682.trc:
Thu May  7 09:19:12 2009
Trace dumping is performing id=[cdmp_20090507091857]
Thu May  7 09:20:52 2009
Waiting for clusterware split-brain resolution
Thu May  7 09:25:55 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lmon_114856.trc:
ORA-00600: Message 600 not found; No message file for product=RDBMS, facility=ORA; arguments: [kjxgrdecidemem1]
Thu May  7 09:25:56 2009
Trace dumping is performing id=[cdmp_20090507092556]
Thu May  7 09:25:56 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lmon_114856.trc:
ORA-00600: Message 600 not found; No message file for product=RDBMS, facility=ORA; arguments: [kjxgrdecidemem1]
Thu May  7 09:25:56 2009
LMON: terminating instance due to error 481
Instance terminated by LMON, pid = 114856

明天還要去客戶現場，又是9點到，還在南城，睡覺～

未完待續～～～～～～～～～～

還是繼續寫完吧～～～～～～～

後來經過檢查，發現在netstat -s檢視時發現有丟包現象，但是還是沒有引起我的足夠注意，再後來我實在是找不到原因，只好建議客戶從網路和系統方面都排查！正好這時候客戶請來另一家的工程師解決，我覺得人家在兩個方面做得比我好：

1、先是去看了現場硬體配置環境（我就沒去看過）

2、從可能的原因一一排查（我就一直專注於找到比較可信的原因）

可能是在一家公司呆久了，也可能是經常一個人解決問題，行成了自己的固定思維模式，總之，最後是我沒有找到比較可行的解決方法，而另一家公司的工程師建議客戶排除網路（心跳線等原因）、系統等方面，再想起他方法，結果心跳線一換就ok啦～～～～～～～