Oracle RAC 導致例項驅逐的五大原因[ID 1526186.1]

這篇文件在MOS上看到被翻譯成了中文，覺得比較實用，因此貼出來方便別人查閱，後期會盡量多貼一些MOS上的中文技術資料，希望可以幫到別人，同時也算自己學習的一個過程。

 Database - Enterprise Edition - Version 10.2.0.1 to 11.2.0.3 [Release 10.2 to 11.2]
Information in this document applies to any platform.

本文件針對導致例項驅逐的主要問題為 DBA 提供了一個快速概述。

 

DBA

 

問題 1：警報日誌顯示 ora-29740 是例項崩潰/驅逐的原因

症狀：

例項崩潰，警報日誌顯示“ORA-29740:evicted by member ...（被成員...驅逐）”錯誤。

可能的原因：

一個例項將另一個例項從 RAC 資料庫驅逐時，出現了 ORA-29740 錯誤。被驅逐的例項會在警報日誌中報告 ora-29740 錯誤。此問題的部分原因是叢集中的通訊錯誤、向控制檔案傳送“心跳”失敗以及其它原因。
檢查所有例項的 lmon 跟蹤檔案，這對確定例項驅逐的原因程式碼而言非常重要。查詢包含“kjxgrrcfgchk:Initiating reconfig”的行。這將提供一個原因程式碼，如“kjxgrrcfgchk:Initiating reconfig, reason 3”。例項驅逐時發生的大多數 ora-29740 錯誤是由於原因 3（“通訊故障”） 造成的。
Document 219361.1 (Troubleshooting ORA-29740 in a RAC Environment) 介紹了以下幾種可能造成原因 3的 ora-29740 錯誤原因：
a) 網路問題。
b) 資源耗盡（CPU、I/O 等）
c) 嚴重的資料庫爭用。
d) Oracle bug。

解決方案：

1) 檢查網路，確保無網路錯誤，如 UDP 錯誤或 IP 資料包丟失或故障錯誤。
2) 檢查網路配置，確保所有節點上的所有網路配置均設定正確。例如，所有節點上 MTU 的大小必須相同，並且如果使用巨幀，交換機也能夠支援大小為 9000 的 MTU。
3) 檢查伺服器是否存在 CPU 負載問題或可用記憶體不足。
4) 檢查資料庫在例項驅逐之前是否正處於掛起狀態或存在嚴重的效能問題。
5) 檢查 CHM (Cluster Health Monitor) 輸出，以檢視伺服器是否存在 CPU 或記憶體負載問題、網路問題或者 lmd或 lms 程式出現死迴圈。CHM 輸出只能在特定平臺和版本中使用，因此請參閱 CHM 常見問題Document 1328466.1
6) 如果 OSWatcher 尚未設定，請按照Document 301137.1中的說明進行設定以執行 OSWatcher。 CHM 輸出不可用時，使用 OSWatcher 輸出將有所幫助。

 

問題 2：警報日誌在例項崩潰或驅逐前顯示“ipc send timeout”錯誤

症狀：

例項驅逐時，警報日誌顯示許多“IPC send timeout”錯誤。此訊息通常伴隨資料庫效能問題。

可能的原因：

在 RAC 中，資料庫程式，例如 lmon、lmd 和 lms 會不斷地和其他例項的程式通訊。lmd0 程式負責管理 enqueue，而 lms 程式負責管理資料塊資源並傳輸資料塊以支援 Cache Fusion。如果這些程式中的一個或多個受阻、死迴圈或異常繁忙，則可能導致“IPC send timeout（IPC 傳送超時）”錯誤。
lmon、lms 和 lmd 程式報告“IPC send timeout”錯誤的另一個原因是網路問題或伺服器資源（CPU 和記憶體）問題。這些程式可能無法獲得 CPU 執行排程或這些程式傳送的網路資料包丟失。涉及 lmon、lmd 和 lms 程式的通訊問題導致例項驅逐。被驅逐例項的警報日誌顯示的資訊類似於如下示例：

IPC Send timeout detected.Sender: ospid 1519
Receiver: inst 8 binc 997466802 ospid 23309
如果某例項被驅逐，警報日誌中的“IPC Send timeout detected（檢測到 IPC 傳送超時）”通常伴隨著其它問題，如 ora-29740 和“Waiting for clusterware split-brain resolution（等待叢集件“腦裂”解決方案）”

解決方案：

===>此處的解決方案與問題 1 相似
1) 檢查網路，確保無網路錯誤，如 UDP 錯誤或 IP 資料包丟失或故障錯誤。
2) 檢查網路配置，確保所有節點上的所有網路配置均設定正確。例如，所有節點上 MTU 的大小必須相同，並且如果使用巨幀，交換機也能夠支援大小為 9000 的 MTU。
3) 檢查伺服器是否存在 CPU 負載問題或可用記憶體不足。
4) 檢查資料庫在例項驅逐之前是否正處於掛起狀態或存在嚴重的效能問題。
5) 檢查 CHM (Cluster Health Monitor) 輸出，以檢視伺服器是否存在 CPU 或記憶體負載問題、網路問題或者 lmd或 lms 程式出現死迴圈。CHM 輸出只能在特定平臺和版本中使用，因此請參閱 CHM 常見問題Document 1328466.1
6) 如果 OSWatcher 尚未設定，請按照Document 301137.1中的說明進行設定以執行 OSWatcher。CHM 輸出不可用時，使用 OSWatcher 輸出將有所幫助。

 

問題 3：在例項崩潰或驅逐前，問題例項處於掛起狀態

症狀：

在例項崩潰/驅逐前，該例項或資料庫正處於掛起狀態。當然，也可能是節點掛起。

可能的原因：

由於 lmon、lmd 和 lms 等不同程式與其它例項上對應的程式通訊，因此當例項和資料庫掛起時，這些程式可能正在等待某個資源，如 latch、enqueue 或資料塊。這些等待中的程式得不到網路響應，或無法透過網路向遠端例項傳送任何通訊。因此，其它例項將驅逐問題例項。
在執行驅逐其他例項動作的例項警報日誌中，您可能會看到與以下訊息類似的訊息：
Remote instance kill is issued [112:1]:8
或者
Evicting instance 2 from cluster

解決方案：

1) 查詢資料庫或例項掛起的原因。對資料庫或例項掛起問題進行故障排除時，獲取全域性 systemstate 轉儲和全域性hang analyze 轉儲是關鍵。如果無法獲取全域性 systemstate 轉儲，則應獲取在大致相同時間所有例項的本地 systemstate 轉儲。
2) 檢查 CHM (Cluster Health Monitor) 輸出，以檢視伺服器是否存在 CPU 或記憶體負載問題、網路問題或者 lmd或 lms 程式出現死迴圈。CHM 輸出只能在某些平臺和版本中使用，因此請參閱 CHM 常見問題Document 1328466.1
3) 如果 OSWatcher 尚未設定，請按照Document 301137.1中的說明進行設定以執行 OSWatcher。CHM 輸出不可用時，使用 OSWatcher 輸出將有所幫助。

 

問題 4：在一個或多個例項崩潰或驅逐前，警報日誌顯示“Waiting for clusterware split-brain resolution（等待叢集“腦裂”解決方案）”

症狀：

在一個或多個例項崩潰之前，警報日誌顯示“Waiting for clusterware split-brain resolution（等待叢集件“腦裂”解決方案）”。這通常伴隨著“Evicting instance n from cluster（從叢集驅逐例項 n）”，其中 n 是指被驅逐的例項編號。

可能的原因：

lmon 程式向遠端例項傳送一個網路 ping，如果遠端例項上的 lmon 程式不響應，則出現例項級別的“腦裂”。因此，查詢 lmon 不能相互通訊的原因對解決此問題而言非常重要。
常見原因有：
1) 例項級別的“腦裂”通常由網路問題導致，因此檢查網路設定和連線非常重要。但是，因為如果網路已關閉，叢集件 (CRS) 就會出現故障，所以只要 CRS 和資料庫使用同一網路，則網路不太可能會關閉。 
2) 伺服器非常繁忙和/或可用記憶體量低（頻繁的交換和記憶體掃描），將阻止 lmon 程式被排程。
3) 資料庫或例項正處於掛起狀態，並且 lmon 程式受阻。
4) Oracle bug
以上原因與問題 1的原因相似（警報日誌顯示 ora-29740 是例項崩潰/驅逐的原因）。

解決方案：

===>此處的解決方案與問題 1 相似
1) 檢查網路，確保無網路錯誤，如 UDP 錯誤或 IP 資料包丟失或故障錯誤。
2) 檢查網路配置，確保所有節點上的所有網路配置均設定正確。例如，所有節點上 MTU 的大小必須相同，並且如果使用巨幀，交換機也能夠支援大小為 9000 的 MTU。
3) 檢查伺服器是否存在 CPU 負載問題或可用記憶體不足。
4) 檢查資料庫在例項驅逐之前是否正處於掛起狀態或存在嚴重的效能問題。
5) 檢查 CHM (Cluster Health Monitor) 輸出，以檢視伺服器是否存在 CPU 或記憶體負載問題、網路問題或者 lmd或 lms 程式出現死迴圈。CHM 輸出只能在特定平臺和版本中使用，因此請參閱 CHM 常見問題Document 1328466.1
6) 如果 OSWatcher 尚未設定，請按照Document 301137.1中的說明進行設定以執行 OSWatcher。CHM 輸出不可用時，使用 OSWatcher 輸出將有所幫助。

 

問題 5：另一個實??嘗試驅逐問題例項，但由於一些原因未能成功驅逐，最終CRS會終止該問題例項。

症狀：

一個例項驅逐其他例項時，在問題例項自己關閉之前，所有例項都處於等待狀態，但是如果問題例項因為某些原因不能終止自己，發起驅逐的例項將發出 Member Kill 請求。Member Kill 請求會要求 CRS 終止問題例項。此功能適用於 11.1 及更高版本。

可能的原因：

要求 CRS 終止問題例項的例項警報日誌顯示
Remote instance kill is issued [112:1]:8
例如，以上訊息表示終止例項 8 的 Member Kill 請求已傳送至 CRS。
問題例項由於某種原因正處於掛起狀態且無響應。這可能是由於節點存在 CPU 和記憶體問題，並且問題例項的程式無法獲得 CPU 執行排程。
第二個常見原因是資料庫資源爭用嚴重，導致問題例項無法完成遠端例項驅逐該例項的請求。 
另一個原因可能是由於例項嘗試中止自己時，一個或多個程式“倖存”了下來。除非例項的所有程式全部終止，否則 CRS 不認為該例項已終止，而且不會通知其它例項該問題例項已經被終止。這種情況下的一個常見問題是一個或多個程式變成殭屍程式且未終止。並導致CRS透過節點重啟或 rebootless restart（ CRS 重新啟動但節點不重啟）進行重新啟動。這種情況下，問題例項的警報日誌顯示
Instance termination failed to kill one or more processes
Instance terminated by LMON, pid = 23305
（例項終止未能終止一個或多個程式例項被 LMON, pid = 23305 終止）

解決方案：

===>此問題的解決方案與問題 3 相似
1) 查詢資料庫或例項掛起的原因。對資料庫或例項掛起問題進行故障排除時，獲取全域性 systemstate 轉儲和全域性hang analyze 轉儲是關鍵。如果無法獲取全域性 systemstate 轉儲，則應獲取在大致相同時間所有例項的本地 systemstate 轉儲。
2) 檢查 CHM (Cluster Health Monitor) 輸出，以檢視伺服器是否存在 CPU 或記憶體負載問題、網路問題或者 lmd或 lms 程式出現死迴圈。CHM 輸出只能在某些平臺和版本中使用，因此請參閱 CHM 常見問題Document 1328466.1
3) 如果 OSWatcher 尚未設定，請按照Document 301137.1中的說明進行設定以執行 OSWatcher。CHM 輸出不可用時，使用 OSWatcher 輸出將有所幫助.

 

NOTE:1328466.1 - Cluster Health Monitor (CHM) FAQ
NOTE:1375405.1 - Top 5 RAC Instance Crash Issues
NOTE:219361.1 - Troubleshooting ORA-29740 in a RAC Environment
NOTE:301137.1 - OSWatcher Black Box User Guide (Includes: [Video])