關于ORA-00020問題的反思

今天在生産環境中檢視alert日志，發現了如下的一段錯誤。這個錯誤确實沒有太多需要解釋的。很明顯就是因為session leak的經典問題。

ORA-00020: maximum number of processes 5000 exceeded

ORA-20 errors will not be written to the alert log for

 the next minute. Please look at trace files to see all

 the ORA-20 errors.

Fri Sep 19 12:39:38 2014

Process W001 submission faile

這個問題的分析思路就是檢視對應的awr報告。可以得到一些資訊。

如果能夠定位到一些明顯的問題，那就很順利了，如果不行，還得縮小時間範圍。看看ash報告找到更多的資訊。

              Snap Id      Snap Time      Sessions Curs/Sess

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

Begin Snap:     14866 19-Sep-14 12:00:13     3,926       3.6

  End Snap:     14867 19-Sep-14 13:00:17     2,693       6.7

   Elapsed:               60.07 (mins)

   DB Time:            4,202.97 (mins)

ash報告雖然可以提供很多有效的問題處理思路，但是對于session的監控卻無能為力。

而且ASH中得到的是active session的一些資訊，比如應用存在問題，連接配接沒有及時釋放，這些session都是在inactive狀态，在ash報告中也不會展現。

awr報告中如果兩個快照的時間夠短，可能得到的session的資訊就比較詳細了，但是session的資訊是實時變化的，快照的間隔太短也不現實。

這個時候個人建議就是自己寫一寫腳本來監控session的情況。盡管很多的曆史資訊都可以在Oracle中查到，但是根據需要oracle滿足不了我們很多的需求。

提供一些分子的檔案庫也是對oracle的補充，而且出了問題之後能夠更加快捷有效的排查問題。

比如說上面這個ora錯誤，一般從大體的角度都會問幾個問題。

一般生産環境的session情況是怎麼樣的。

這個問題出現的頻率，從什麼時候開始出現的。

怎麼預防。

如果沒有一些資料支援，是最怕上司這麼問的。但是一旦你有了自己的檔案庫，不完全依賴于資料庫，就會有得到很多的額外收獲。

這個時候一個簡單清晰的圖示就可以讓上司一目了然。

以上是一個簡單的截圖部分，資料的情況就一目了然了。有幾天的session數特别低，那是因為做了更新工作。之後session數開始抖動。就能夠比較及時的發現問題。

至于說怎麼預防，還得和開發部門協調，但是從dba的角度來說我們能夠提供足夠的資訊和支援。