關於session leak的問題分析

在生產環境中，作為dba需要對系統的負載有一個很清晰的認識。能夠在很快的時間內能夠發現系統潛在的問題，並且及時定位問題，高效的響應和處理問題。
比如說對於生產環境的session leak問題，這個部分是awr都很難捕捉到的資訊，如果問題比較隱蔽，連ash也很難定位。
比如說在早上9點的時候某個程式出現了session leak的問題，有些程式的處理不能及時的關閉連線，到時連線數急劇增加，但是因為這個過程中，那些連線到資料庫session沒有再處理資料，就變成了Inactivie了，這部分資訊ash也是很難捕捉到的。同時系統的負載會有一定的提升，系統看似很忙，其實沒有處理更多的資訊。這種情況可以簡單理解為session leak的一種體現。
這個時候我的建議是能夠通過一套完善的監控體系來作為oracle工具集的補充，畢竟很多型別的問題，oracle不會都解決完。有些甚至可以自己去寫一些指令碼之類的來完成。
對session的監控就顯得很有意義，我說的session監控，不只是包括active的session，而且包括inactive的session.
比如如下的圖表，通過監控工具可以看到在這個下午的時間內，active session都在50個以內，從這些資料來看，判斷不出系統到底有沒有問題。



如果我們現在假設系統的session數目前最大支援5000~6000，那麼就可以設定一個閥值，超過某一個閥值，就是警戒線，就可以說明session存在一定的問題，需要檢查，如果再設定一個閥值，超過了這個閥值，就需要立刻做出響應。
對於5000個session的庫來說，目前我設定的閥值就是3000~35000，如果session在這個範圍內，就需要引起重視，排查到底是什麼原因導致的，設定的第二個閥值是4000，如果超過這個範圍，問題就很緊急了，需要馬上做出響應。儘快的定位問題，及時處理。

回到上面的那個圖表，從圖表上來說，active session在50個以內，完全不是什麼問題。但是我通過一定的指令碼得到下面這個列表就會發現這個問題是多麼的嚴重。

STATUS          CNT

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

ACTIVE           58

INACTIVE       4889

         ----------

sum            4947

一共5000的session，現在達到了4900多，已經沒有多少富餘的session了。需要馬上定位問題。
首先是需要定位session佔用過多的program部分是哪些。通過如下的排查馬上可以發現jdbc客戶端中佔用了過多的session。

PROGRAM                                    CNT STATUS

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

JDBC Thin Client                          4338 INACTIVE

extract@xxxxxxx(TNS V1-V3)                60 INACTIVE

java_q4p@xxxxxxxx(TNS V1-V3)               40 INACTIVE

java@xxxxxxxx(TNS V1-V3)                   31 INACTIVE

java_q4p@xxxxxxxx(TNS V1-V3)               31 INACTIVE

.......

定位了program的部分，就開始定位machine,username。更多的監控資訊可以參考
通過shell指令碼監控oracle session 
http://blog.itpub.net/23718752/viewspace-776143/
馬上能夠定位到session是從某臺伺服器上連過來的，這個時候就需要馬上定位這臺伺服器上執行的程式。
可以通過隨機抓取一部分session的資訊，然後通過sid來檢視目前inactive 狀態的session之前執行的sql語句來排查。
select sql_id prev_sql_id ,sql_text from v\$sql where sql_id in (select prev_sql_id sql_id from v$session where  (sid||','||serial#)='$1'  ) and rownum<2;
通過這些步驟肯定能夠得到一些有用的資訊。
今天的這個案例中，我發現很多inactive的session都是連續的，我就隨機抓取了2個session，然後從檢視執行過的sql記錄，發現都是同一個insert語句。這樣可以提供這些資訊給相應的開發和系統部分來馬上處理。
經過排查，他們發現確實是一個session leak的問題，經過討論，啟用了2個job在處理，佔用了過多的資源，但是這兩個job的優先順序不是很高，所以可以稍後處理，就這樣把這兩個job先停掉，session的佔用率馬上就降下來了。
通過這個問題的排查是想說明不要完全依賴某個工具，要有自己的思路來處理問題，設定session的管理閥值就是一個衡量系統健康的指標。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1287641/，如需轉載，請註明出處，否則將追究法律責任。