今天在生產環境中檢視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的角度來說我們能夠提供足夠的資訊和支援。