一次交換空間設定不合理引發的故障

n   2014 年12月29日9:30至11:00,2015年1月7日23:00左右，2015年1月12日11:00左右，某客戶資料庫分別出現不同程度的故障，最終都通過重啟資料庫或者主機解決。

2014 年12月29日9:30至11:00，2015年1月7日23：30左右，2015年1月12日11：00左右，資料庫分別出現不同程度的故障，最終都通過重啟資料庫或者主機解決。通過檢視其它廠商的故障分析報告，仔細分析故障前後的Oracle的AWR報告、作業系統日誌，veritas等軟體日誌，得出如下結論：

資料庫故障主要是由於資料庫內部的區域性故障導致大量業務程式重連積壓，進一步消耗了系統記憶體。在交換空間配置不合理的情況下（故障時系統記憶體為32GB，交換空間配置為8GB），交換空間使用率為100%，進而導致資料庫全面故障，業務操作幾乎hang。

時間點	故障處理關鍵點
6/09 9:30~16:30	現場收集日誌，分析故障
6/10 8:30	寫故障分析報告

n    

事後故障分析，依賴於各類日誌，經過採集。故障發生前後，各類日誌收集如下：

故障時間點	AWR 報告	系統日誌	Veritas 日誌	Oracle alert log	Oracle CRS log
12 月29日9:30至11:00	無，但有故障前報告（9:00至9:30）	有，但無明顯報錯	有	有	有
1 月7日23:30左右	無，但有故障前報告（19:00至22:30）	有，但無明顯報錯	有	有	有
1 月12日11:00左右	無	有，但無明顯報錯	有	有	有

由於 1 月12日故障，缺少AWR報告，所以無法分析業務層面的故障原因。本次故障報告我們重點分析12月29日和1月7日的故障。

12 月29日的故障發生在9：30分至11:00左右，屬於業務高峰期。故障發生時刻，szybdb1系統交換空間使用率已經達到91%以上，engine_A.log日誌如下所示：

檢視故障前一刻1號節點的AWR報告，主要等待事件如下：

等待事件enq:TC-contention，gc current request，enq:TX-row lock contention，enq:RO-fast object reuse耗時都達到了500ms以上，這是極不正常的。當系統出現以上長時間的等待事件時，業務程式肯定接近於hang。正常情況下，以上等待事件耗時應該在1ms以下。

根據經驗，enq:TC-contention，gc current request，enq:RO-fast object reuse ，enq:TX-row lock contention同時出現長時間等待往往是由於交換空間緊張引起的，這跟觀察到的交換空間使用接近100%相吻合。enq:TX-row lock contention是值得注意的等待事件， 進一步檢視1號節點AWR報告顯示，發現insert KC66表是引起enq:TX-row lock contention的最大原因，AWR報告取樣期間改SQL沒有執行成功，如下所示：

在2號節點insert KC66表執行次數較為頻繁，如下所示：

基於以上分析，很可能是儲存過程SIM_UserPack.oraP033和SIM_UserPack.oraP028或者SIM_UserPack.oraP029執行時產生了衝突，應用程式不停的發起重連線，進而導致資料庫會話數急劇上漲 。截止資料庫重啟前，單個節點的會話數由平時的90個左右上升到672個。Oracle警告日誌如下所示：

故障時，主機記憶體為32G，SGA分配16G。按照每個會話佔用5M左右的記憶體，作業系統佔用記憶體2GB來估算，那麼總體需要記憶體為：16*1024+5*672+2*1024=16384+3360+2048=21792MB。 根據以上演算法，總體來講，記憶體應該是夠的。HP-UX在早期版本時，程式在記憶體中執行前需要在交換裝置上預留相同大小的空間，所以要求交換空間的大小和記憶體大小保持一致。也就是說如果作業系統記憶體為32GB，交換空間只有8GB，那麼原則上只能使用8GB的記憶體，當記憶體使用量超過8GB時，則會出現交換空間使用100%，程式無法malloc 或 fork 失敗，嚴重情況下會導致資料庫hang死故障。如本次故障時，資料庫程式則無法fork，警告日誌如下所示:

為了節省交換空間，HP-UX推出了pseudo swap 特性。Pseudo swap 可使系統管理員利用具有較大物理 記憶體的系統，而無須配置較大的 swap 區域。Pseudo swap 不是裝置 swap 的替代品，而是 swap 的增強。當系統引導時，會計算 pseudo swap 的數量。此計算是 75% 的實體記憶體，此值是不可調整核心引數。該 Kernel 會此增強看作是產生新程式時可以分配的附加 swap 區域。系統只會將 pseudo swap 用作保留空間，而不會將程式分頁進出 pseudo swap。如果程式需要分頁出實體記憶體，Kernel 則會 swap 到裝置或檔案系統 swap。醫保系統使用了pseudo swap特性，即在32GB記憶體，8GB交換空間的情況下，總的交換空間可以達到8GB+32GB*0.75=32GB。但需要注意的是， pseudo swap特性不適用於負載比較重的的系統，當負載比較重時，pseudo swap和swap物理裝置的協調就會出現問題，進而瞬間導致swap空間使用率達到100%。所以12月19日的故障是由於應用程式insert kc66不成功，應用程式不停的發起重連線，進而導致資料庫會話數急劇上漲（達到了672個），進一步消耗了作業系統記憶體。由於交換空間設定不足，從而導致業務大規模hang死。

需要指出的是，insert KC66操作應該是特定時間段的操作，在已有的其他的AWR報告中沒有發現此類SQL或者很少，這個需要跟業務開發商再次確認。

需要說明的是，1月7日故障發生時23:30，即szybdb1和szybdb2主機的SWAP空間相對空閒， 這跟12月29日發生的故障現象有所區別：

而資料庫層面除了執行正常的SQL之外，還在執行統計資訊分析操作，AWR報告如下圖所示：

統計資訊收集為Oracle後臺自動發起，主要為CBO產生SQL執行計劃時提供參考，從而優化資料庫效能（絕大多數情況下）。在個別情況下，統計資訊自動收集時會影響部分SQL的執行效能。如果業務變化不大或者資料庫規模變化不大的情況下，從穩定性角度出發建議關閉統計資訊自動收集。

 

1 、目前系統記憶體配置為64GB，交換空間由原來的8GB增加到32GB。在64GB的情況下，建議交換空間增加到64GB。否則依然有swap空間不足的風險，但發生概率會降低。

2 、重連線時控制中介軟體tuxedo連線池數量，比如每個節點150（正常情況下在100左右），從而防止大量的重連操作急劇消耗主機記憶體。

3 、建議業務廠商調查儲過程SIM_UserPack.oraP033和SIM_UserPack.oraP028或者SIM_UserPack.oraP029執行時產生衝突的可能性。

4 、關閉統計資訊自動執行。