關於ORA-00020問題的反思

來源:互聯網
上載者:User

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

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

Tags Index: