編輯手記：資料庫中每一個不起眼的引數，都有其內部的原理，不可隨意更改。今天分享一則因核心引數SEMOPM設定太小，加上在業務高併發時段LGWR寫入太慢，系統呼叫失敗，最終資料庫異常宕機的案例。

故障現象

資料庫CRASH，在CRASH前，ALERT中顯示如下的日誌內容

我們看到中間有27300和27301的錯誤。

27300：OSsystemdependentoperation:stringfailedwithstatus:string，作業系統呼叫失敗。

原因分析

1、後臺日誌分析

在某天08:59:34.664000+08:00開始，出現大量下面日誌資訊：

此錯誤是前臺程序等待LGWR返回結果，但是LGWR一直沒有返回，前臺程序認為LGWR出現致命的錯誤。

在隨後出現下面的日誌資訊：

這裡顯示LGWR程序在POSTPROCESS時，呼叫semop程序出現狀態7的錯誤，文字描述是Argumentlisttoolong，對應的變數是E2BIG。

錯誤函式變數定義，manerrno:

E2BIGArgumentlisttoolong(POSIX.1)

semop錯誤說明

E2BIGTheargumentnsopsisgreaterthanSEMOPM,themaximumnumberofoperationsallowedpersystemcall.

說明程序在systemcall時，如果nsops的值大於系統配置的SEMOPM時就會報E2BIG錯誤。

2、主機引數配置

檢視系統引數配置

這裡看到SEMOPM的值為100，在ORA-27303報錯時，顯示值112，大於系統配置的100的，所以LGWR一次SYSTEMCALL不能POST所有前臺程序，部分前臺程序認為LGWR程序出現致命錯誤，最後導致資料庫自動重啟。

3、分析SEMOPM為112原因

查詢ASH資料

由於ASH最近1小時的資料都是存放在記憶體中，資料庫CRASH時，並沒有將記憶體中的資料寫入資料檔案中，所以這裡不能從ASH中查詢到任何的資訊

檢視作業系統LGWR,DIAG日誌

主機上面無重啟前的LGWR,DIAG日誌資訊。

最近資料庫效能趨勢

該資料庫從故障前十天左右號某業務上線後，資料庫每秒的REDO達到20~40M，物理IO也讀達到200M/S以上，寫達到100M/S，網路流量達到60M/S，IO延遲與網路延遲都很嚴重，所以懷疑是在高併發情況下，導致資料庫日誌寫入慢，大量前臺程序（報錯時112）等待LGWR的POST資訊，超過核心引數配置的100值。

處理建議

修改主機kernel.sem的值，建議修改成跟模板資料庫一致，修改此引數需要重啟資料庫。

後續工作

1、優化該資料庫的SQL，減少物理讀，出賬結束後就開始收集優化資訊。

2、增加主機CPU資源，修改網路繫結的方式，減少網絡卡軟中斷的次數與包重傳的次數。

3、考慮重啟主機。

4、繼續跟開發一起分析業務，查詢為什麼業務執行次數與AWR中SQL統計的次數差異很大，找到日誌量變換的原因。

5、更換更好的儲存，提高IO效能。

文章出處：Oracle訂閱號