關於ORA-00020問題的反思

關於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的角度來說我們能夠提供足夠的資訊和支援。