前言

換句話說:

當Oracle RAC集群中的一個節點所在的分區/服務器宕掉的時候，

你是否可以和領導拍著胸脯說，

“沒事，這是ORACLE RAC，還有一個節點呢！只要該節點可以抗住負載，完全可以正常對外提供服務！”

如果你再把上面那段話讀一遍，是否有開始猶豫的感覺了呢？

小y再換個方法來問一下這個話題：

雖然系統上線前做過RAC高可用測試，但是當集群中的一個節點長時間運行，包括CPU、內存、進程數在內的負載在不斷變化，并且又經歷了一些列變更后，期間又沒有再做過高可用測試，這樣的情況下，如果RAC一個節點所在的分區/服務器宕掉的時候，你是否依然可以拍著胸脯堅定的說，“我的Oracle RAC其他的節點一定可以正常對外提供服務！”?

同樣的問題，當多了一些話語的鋪墊后，再次聽到這個問題的你，答案是否又更加猶豫了呢？

小y今天就為大家奉獻一個“RAC高可用丟失”的真實案例及其完整、真實的分析過程。

了解到導致Oracle RAC高可用失效的一些具體因素。

小y估計不少朋友的系統中依然還存在類似的問題，

建議參考本案例進行細致檢查,排除隱患。

現象：Oracle RAC高可用丟失。 表現如下

1）下午16點1分左右，XX系統數據庫RAC集群節點2所在的P595   發生硬件故障，導致節點2 數據庫所在的分區不可用。

2）但從16點1分開始，應用程序無法連接到數據庫RAC集群中存活的節點1。

ORACLE數據庫RAC集群未能發揮高可用架構的作用！

客戶指示，務必找到問題根因，以便對系統高可用架構提出改進意見。

小y很理解，出了這樣的大事，對于一個運行著幾百套RAC的數據中心而言，是一個巨大的風險，其他系統是否也還存在這樣的問題？什么時候會再發生？如果不找到問題根因，又如何做到由點帶面全面全面梳理、檢查和預防呢？

環境描述:

AIX 5.3

Oracle 10.2 2節點 RAC

HACMP+裸設備

所以，小y接到該case時，還是有很大壓力的。在開始分析前，小y得到了以下信息：

1）故障時運維DBA在RAC存活節點1通過sqlplus “/as sysdba”連接到數據庫掛起

2）故障時運維DBA在RAC存活節點1通過sqlplus -prelim “/as sysdba”連接到數據庫掛起,加了-prelim參數連接到數據庫也hang,這是很罕見的情況

3）在存活的節點1上通過 crsctl stop crs -f停止crs無法停止,命令掛起無法結束

4）在存活的節點1上通過shutdown –Fr重啟操作系統，命令掛起無法結束，最終通過hmc重啟分區，業務恢復正常

集群中一個節點宕掉，其他節點無法對外提供服務。

通常情況下，是因為當中的集群軟件沒有完成對整個集群狀態、數據的重組，

因此數據未達到一致，所以集群其他節點無法對外提供服務。

這個環境中部署在IBM小機上，其中用到的集群軟件有：

ORACLE RAC/ORACLE CRS/IBM HACMP

因此，需要分別查看這三個集群是否完成了重組、重新配置

查看一節點數據庫alert日志,可以看到，RAC集群在16點1分32秒就完成了重組。

可排除該問題。

經AIX專家分析，未發現HACMP中出現異常

整個檢查下來，沒有發現異常。

既然節點2數據庫所在的Lpar宕了，那么節點2的vip應該會漂移到節點1上，接下來通過netstat –in命令檢查，發現節點1上居然沒有節點2飄過來的VIP ！

接管VIP的動作最終將由CRSD進程來完成，因此檢查CRSD.log,以便查看是否在接管過程中發生了什么異常。

可以看到：

1）節點2當掉后，節點1的CRS要把節點2的vip、db等資源接管過來，在節點1啟動，但是調用腳本racgwarp來做check/start/stop時均出現了超時timeout,從而把子進程終止了。

2）并且節點1 本身自己的 vip檢測中也出現了超時，如下所示

/oracle/app/oracle/product/10.2.0/crs/bin/racgwrap(check) timed out for ora.node1.vip! (timeout=60)

3） 因此，CRS在資源管理上也出現了一定的異常，主要是調用腳本racgwrap時出現了超時異常。

Racgwrap腳本出現timeout,通常是因為：

?  操作系統性能緩慢，如內存大量換頁

?  腳本執行過程出現命令掛起的情況

那么，接下來，我們的分析重點到底是放在數據庫還是操作系統層面呢？

通過上面的線索梳理，我們有理由相信：

操作系統在當時出現了某些異常!因此后續把分析的重點方向放在操作系統層面！

1）存活節點Sqlplus –prelim無法attach到共享內存

2）Kill -9 無法殺掉部分進程

進程處于一個原子級的調用，例如一個IO，必須在兩個調用之間才可以接受進程終止的信號，說明某個原子調用無法結束導致無法被kill -9終止

3）CRS通過腳本無法接管故障節點vip,出現超時

4）CRS通過腳本無法檢測存活節點本身的vip/監聽等資源，均出現超時

5）存活節點Nmon故障點后無輸出

雖然把方向放在操作系統上，但AIX專家未檢查到異常。

AIX專家的結論是操作系統當時是沒有異常的！

因為他們檢查了一些crontab的腳本，是有輸出的，說明OS還在工作。

如下圖所示

小y把方向定到了操作系統，但是操作系統專家檢查并否認操作系統有異常。

對于存活節點nmon為什么停止寫入的問題，雙方持不同意見。

至此，問題分析陷入僵局，小y開始思考，該如何繼續往下分析呢？怎么能證明操作系統的異常呢？

1)如果沒有給到操作系統一個明確的點，那么操作系統是很難查到到底有哪些異常的問題

2)問題分析陷入僵局，該如何找到突破口成為關鍵

3)堅信操作系統異常這個方向是正確的

回到原點，重新梳理和驗證每個線索，會不會漏掉了什么重要線索

可以看到 ：

從16點02分以及后續的的采樣可以看到，到了” The file system result is as follows”的檢測就停止了，沒有寫SYSTEM.SH_RUN_COMPLETE關鍵字來表示腳本執行完成.這說明操作系統在執行 非數據庫命令 時也遇到了異常！

檢查shell腳本,發現腳本掛在” The file system result is as follows:”的地方，事實上是調用了df命令來查看文件系統。

那么這個操作在什么情況會出現HANG的情況呢。

答案是使用nfs文件系統的時候。

XX系統數據庫集群中使用了NFS文件系統，將節點2的/arch3文件系統通過NFS掛載到了節點1的/arch3文件系統上。當節點2出現硬件故障后，導致節點1無法與節點2的nfs server通訊，繼而導致節點1上，df命令查看文件系統時掛起。

由此來看，節點1 nmon數據停止的原因是df命令hang住了

但是這和節點1無法連接數據庫又有什么關系呢？

當小y看到df命令時，淚奔了！

所有現象都可以得到解釋了！當所有現象都得到解釋的時候，心里就踏實了！這意味著你找到了問題的根因，那么預防措施就萬無一失了！

執行連接數據庫操作時，需要獲取當前工作目錄(pwd)

但是由于AIX某些版本操作系統內部實現pwd過程的缺陷,導致必須遞歸到根目錄/下檢查目錄或文件的權限、類型.

當檢查到nfs時，由于nfs 以hard/background方式掛載，當nfs server不可用時，必然導致檢查nfs目錄時出現掛起，繼而導致了無法獲得pwd的輸出結果，繼而導致無法連接數據庫!

1）  存活節點Sqlplus –prelim無法attach到共享內存

獲取當前工作目錄時，由于nfs mount點丟失，get_cwd(pwd)掛起

2）  Kill -9 無法殺掉部分進程

進程對nfs mount點進行IO操作，掛起，因此沒有機會收到進程終止信號

3）  CRS通過腳本無法接管故障節點vip,出現超時

Racgwrap腳本中調用了pwd命令

4）  CRS通過腳本無法檢測存活節點本身的vip/監聽等資源，均出現超時

Racgwrap腳本中調用了pwd命令

5）  存活節點Nmon故障點后無輸出

Nfs mount點丟失導致nmon調用df命令時掛起

1.該機制下，如果根目錄/小文件或目錄很多，則pwd(get_cwd)的性能會很差

2.測試環境重現過程

節點2 mount /testfs到節點1的/testfs,停止節點2 nfs服務，未能重現。原因在于pwd的輸出為/oracle, 首字母o比t要小，因此未檢測到/testfs就獲得pwd結果而退出了

節點2 mount /aa到節點1的/aa,停止節點2 nfs服務，未能重現。原因是通過truss命令對比，發現生產和測試環境檢索/根目錄下的行為不一致，繼而檢查OS版本，發現測試環境OS版本較高

3.高版本的OS無法重現，低版本的操作系統可以重現，說明操作系統做了修正和增強，在ibm.com上已nfs hang搜索，可以發現IBM發布了APAR來修復該問題。

1、RAC集群節點2所在的P595 發生硬件故障，導致節點2 LPAR不可用。

    繼而導致Nfs mount點丟失。

2、登陸數據庫時，需要獲取當前工作目錄(pwd)

3、但是由于AIX某些版本操作系統內部實現pwd過程的缺陷,導致必須遞        歸到根目錄/下檢查目錄或文件的權限、類型.

4、當檢查到nfs掛載點目錄/arch3時，由于nfs 以hard/background方式      掛載，當nfs server不可用時，必然導致檢查nfs目錄時出現掛起，繼        而導致了無法獲得pwd的輸出結果，繼而導致無法連接數據庫!

以hard/background掛載的NFS server丟失是導致RAC成為偽集群的根本原因！

所有故障現象都可以得到解釋，如下：

1、存活節點Sqlplus –prelim無法attach到共享內存

獲取當前工作目錄時，由于nfs mount點丟失，get_cwd(pwd)掛起

2、Kill -9 無法殺掉部分進程

進程對nfs mount點進行IO操作，掛起，因此沒有機會收到進程終止信號

3、CRS通過腳本無法接管故障節點vip,出現超時

Racgwrap腳本中調用了pwd命令

4、CRS通過腳本無法檢測存活節點本身的vip/監聽等資源，均出現超時

Racgwrap腳本中調用了pwd命令

5、存活節點Nmon故障點后無輸出

Nfs mount點丟失導致nmon調用df命令時掛起

1）  如果需要實用nfs,則mount到二級目錄，比如mount到/home /arch        2而不是/arch3

2）  使用gpfs代替nfs

3）  提供故障線索時，請勿根據個人經驗過濾掉認為不重要的信息

4）  安裝AIX APAR，改變操作系統get_cwd(pwd)調用的內部實現方式

5）  處理故障時Df命令hang的情況如果一開始就反饋給小y，那么這個

      case直接就解開了，就不需要查了！

6） 只在上線前做高可用測試是不夠的，因為上線后系統會經歷一系列的   變更，可能某些因素會報紙RAC冗余性丟失，建議定期做高可用測       試，可以選擇在變更窗口選擇逐個重啟實例、服務器的方式來進行驗證。