分析一次ORACLE數據庫Session暴增的問題

今天中午接到同事求助，說是一個應用裏面報出了一個ORACLE錯誤，因而幫助他看了看，雖然最終沒有解決他的問題（問題不是出在ORACLE數據庫層面），仍是把分析步驟發出來分享一下。

問題狀況：
一個應用程序執行失敗了，在問題日誌中，發現以下報錯。

問題分析：
這個報錯很明顯，是ORA-12519錯誤，具體的意思就是TNS:no appropriate service handler found(沒有合適的服務處理器) ，咱們能夠上網去查一查這個錯誤號，基本的矛頭都指向了數據庫的Session和Process被佔滿。

問題細化分析：

• 執行命令
  select count(*) from v$process ;
select value from v$parameter where name = 'processes' ;
  獲得答案是：：1965和2000
  show parameter session;
select count(*) from v$session;
  獲得答案是：3072和1961
  乍一看，session數尚未吃滿，可是process已經要到峯值了，這個就可能引發ORA-12519。
  而且session雖然沒有吃滿，可是也挺高，因此我接下來的分析偏向Session數部分，後面我會再放一篇文章，來講下其餘狀況。
• 分析V$session表
  其實我一開始分析到這裏，我給的建議是要麼先停庫放掉Session和process，挨個應用啓動看看，要麼找後臺看程序的問題，可是實際業務不容許停庫，找後臺看又過於耗時，因此再打算繼續細化分析一下。
  我首先讓他查一下數據庫當前的鎖表狀況，看看是否是由於某些表鎖了引發session一直增加，查詢後發現沒有鎖表，也就排除了這個可能。
  以後，導出V$session這張表，來進行分析，咱們篩選一下導出後的結果，這張表總數就是1961個，可是其中一個localhost.localdomain這臺機器，有1061個session在sys$user下執行，這明顯不正常。
• 後續的內容，須要現場配合完成
  到這裏我給出的建議是，須要現場結合應用實際狀況，來針對這些異常Session進行分析，找出是哪些應用程序在耗費Session，DBA層面可能只能幫助現場分析到這一步（雖然本身如今還不是，哈哈），後續的內容還得現場來完成。
• 引伸思考，本身有沒有分析的不對的地方？
  我又仔細的縷了一遍問題現象，發現本身貌似沒有關注V$process這張表，因而我又查了一些內容，發現一個問題，那就是：密碼過時會致使Oracle process耗盡

這裏我放一個連接：http://blog.csdn.net/leftfist...

這篇文章說的狀況，大概是這樣的，即Process吃滿，可是Session數特別小，這樣就排除了數據庫自己的操做引發process數的暴漲，跟今天分析的內容不太同樣，可是特別具備預警意義，可能不少11g的oracle都沒有注意這一部分，文章中的描述很詳細，內容也很好，強烈推薦你們看一看。