一次RAC節點宕機的解決過程

1. 狀況介紹

海哥反饋大連某院的Oracle 10g RAC平均每月都要宕機一次，一個節點自動重啓，奇怪的是故障的時間沒有規律，有時還發生在基本上沒有業務的凌晨。醫院目前使用的Windows 2003 Server(32 Bit)，數據庫版本是10.2.0.3。另外海哥還反映系統還伴有Ora-04031錯誤。

2. 問題的診斷過程。

因爲同時出現了down機和ora-04031錯誤，首先判斷是否是因爲內存耗盡，致使的一個節點down機，以前在32bit系統中遇到過相似錯誤;但因爲down機也可能發生在系統壓力很小的凌晨，這一判斷首先被推翻。

向海哥索取了兩個節點的alertSID.log日誌和CRS日誌，開始了分析。

節點１：

----------------------------------------------------------------------------------------------------

IPC Send timeout detected. Receiver ospid 5012

Tue Sep 29 06:18:31 2009 --這個時間檢測到2號節點的IPC超時

Errors in file d:oracleproduct10.2.0adminora10bdumpora101_lms3_5012.trc:

Tue Sep 29 06:19:28 2009

Restarting dead background process DIAG 　--重啓檢測進程進行檢測

DIAG started with pid=3, OS id=68680

Tue Sep 29 06:20:13 2009

Waiting for clusterware split-brain resolution　 --等待「腦裂」方案實施

 

Tue Sep 29 06:24:26 2009

IPC Send timeout detected. Receiver ospid 4768

Tue Sep 29 06:24:26 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora101_lmd0_4768.trc:

 

Tue Sep 29 06:25:29 2009

Restarting dead background process DIAG

DIAG started with pid=3, OS id=71060

Tue Sep 29 06:30:13 2009

Evicting instance 2 from cluster --1號節點將2號節點驅逐出集羣,開始從新配置

Tue Sep 29 06:30:29 2009

Reconfiguration started (old inc 56, new inc 60)

………………省略部分日誌……………………….

Tue Sep 29 07:26:30 2009

Submitted all GCS remote-cache requests

Post SMON to start 1st pass IR

Fix write in gcs resources

Reconfiguration complete --從新配置完成

 

 

節點2：

-------------------------------------------------------------------------------------------------------------------------------

Tue Sep 29 06:18:30 2009

IPC Send timeout detected.Sender: ospid 2112 --檢測到發生了IPC超時

Receiver: inst 1 binc 86089 ospid 5012

Tue Sep 29 06:18:32 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora102_lms1_2112.trc:

ORA-27508: 發送信息時發生 IPC 錯誤

ORA-27300: OS 系統相關操做: IPCSOCK_Send 失敗, 狀態爲: 10055

ORA-27301: OS 故障消息: 因爲系統緩衝區空間不足或隊列已滿，不能執行套接字上的操做。

ORA-27302: 錯誤發生在: send_3

 

Tue Sep 29 06:18:32 2009

IPC Send timeout to 0.4 inc 56 for msg type 65521 from opid 8

Tue Sep 29 06:18:32 2009

Communications reconfiguration: instance_number 1

Tue Sep 29 06:18:32 2009

Trace dumping is performing id=[cdmp_20090929061832]

Tue Sep 29 06:20:13 2009

Waiting for clusterware split-brain resolution --等待「腦裂」方案實施

Tue Sep 29 06:24:25 2009

IPC Send timeout detected.Sender: ospid 2116

Receiver: inst 1 binc 86087 ospid 4768

Tue Sep 29 06:24:27 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora102_lmd0_2116.trc: --這裏是具體的IPC錯誤緣由

ORA-27508: 發送信息時發生 IPC 錯誤

ORA-27300: OS 系統相關操做: IPCSOCK_Send 失敗, 狀態爲: 10055

ORA-27301: OS 故障消息: 因爲系統緩衝區空間不足或隊列已滿，不能執行套接字上的操做。

ORA-27302: 錯誤發生在: send_3

 

Tue Sep 29 06:24:27 2009

IPC Send timeout to 0.0 inc 56 for msg type 65521 from opid 6

Tue Sep 29 06:30:13 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora102_lmon_4008.trc:

ORA-29740: 已被成員 1 逐出, 組原型 58 --檢測到自已經被節點1驅逐

Tue Sep 29 06:30:13 2009

LMON: terminating instance due to error 29740

Tue Sep 29 06:30:13 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora102_lms0_4284.trc:

ORA-29740: 已被成員 逐出, 組原型

 

分析完了日誌，基本能夠肯定是因爲IPC包發送失敗致使CRS認爲心跳失敗，爲了不「腦裂」現象，節點1主動驅逐了節點２;另外的幾回down狀況相似。在一個共享存儲的集羣中，當集羣中hearbeat丟失時，若是各節點仍是同時對共享存儲去進行操做，那麼在這種狀況下所引起的狀況是災難的。ORACLE RAC採用投票算法來解決這個問題，思想是這樣的：每一個節點都有一票，考慮有A，B，C三個節點的集羣情形，當A節點因爲各類緣由不能與B，C節點通訊時，那麼這集羣分紅了兩個DOMAIN,A節點成爲一個DOMAIN，擁有一票；B,C節點成爲一個DOMAIN擁有兩票，那麼這種狀況B，C節點擁有對集羣的控制權，從而把A節點踢出集羣，對要是通IO FENCING來實現。若是是兩節點集羣，則引入了仲裁磁盤，當兩個節點不能通訊時，請求最早到達仲裁磁盤的節點擁用對集羣的控制權。

在網絡正常的狀況下,IPC包發送超時，首先想到是否是遇到了bug， 到Metalink上查了查，發現一個bug與咱們的現象吻合。Bug編號爲： 6782276，在10.2.0.4中獲得了修復。接下來就是循序漸進的打補丁了。