使用awr來分析session leak問題

awr是生產環境中排查問題的利器，但是有一些問題是awr定位不了的。不如session leak的問題，因為v$session中的資料是實時改變的，一來awr生成快照的頻率也有限，二來如果session leak的問題發生,但是系統資源消耗不高，awr也不一定能夠馬上定位出問題所在。
對於session leak的問題，當發生問題的時候，等我們連到系統中的時候，可能問題又消失了。大體來說系統中的session變化基本都是有一定的變化規律的，在業務高峰期中，session會保持在哪個幅度，系統空閒期間，有哪些session,job是在後臺執行，佔用的session數也是有一定的規律的。
從問題排查的角度來看，awr是很難定位session leak問題的，但是我們可以利用awr得到一些有用的資訊。得到了這些問題之後，我們就可以輕鬆的得到在某個時間段內的session大體變化情況。畢竟v$session中的資訊是實時的。
我們想檢視過去某個時間點的session情況，如果沒有第三方的工具，透過資料庫來查詢是基本沒有辦法的。
我們可以從下面的報告中得到一些思路。

	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	21032	27-Nov-14 12:40:41	3686	6.0
End Snap:	21033	27-Nov-14 12:50:41	3648	6.1
Elapsed:		10.01 (mins)
DB Time:		368.84 (mins)

在awr中還是包含一些session的資訊的。如果要檢視最近兩天的session情況，一個一個生成awr基本就是體力活了而且效率很差。我們可以嘗試透過awr的基表來直接得到一些想要的資料。
想要直接檢視awr裡面的資料還是需要下不小的功夫，畢竟從程式碼級別，oracle是不開放這些內容的。透過@?/rdbms/admin/awrextr.sql可以得到一些基本的資訊。
匯出的日誌如下：
. . exported "SYS"."WRH$_SQL_PLAN"                       432.1 KB    1089 rows
. . exported "SYS"."WRH$_LATCH":"WRH$_LATCH_3645037571_0"  198.6 KB    3871 rows
. . exported "SYS"."WRH$_SYSMETRIC_HISTORY"              180.1 KB    3600 rows
. . exported "SYS"."WRH$_SQLSTAT":"WRH$_SQLSTA_3645037571_0"  174.3 KB     547 rows
. . exported "SYS"."WRH$_SQLTEXT"                        162.0 KB     202 rows
. . exported "SYS"."WRH$_SYSSTAT":"WRH$_SYSSTA_3645037571_0"  122.7 KB    4466 rows
. . exported "SYS"."WRH$_PARAMETER":"WRH$_PARAME_3645037571_0"  105.4 KB    2504 rows
. . exported "SYS"."WRH$_EVENT_HISTOGRAM":"WRH$_EVENT__3645037571_0"  81.14 KB    2486 rows
. . exported "SYS"."WRH$_SEG_STAT":"WRH$_SEG_ST_3645037571_0"  71.64 KB     421 rows
. . exported "SYS"."WRH$_SYSMETRIC_SUMMARY"              93.66 KB    1106 rows、
.....
我們可以根據awr報告來尋找對應的基表，畢竟這部分內容是不開放的，我們得根據表明來做一些基本判斷。剩下的就靠運氣了。
最後找到的符合要求的基表是WRH$_RESOURCE_LIMIT，裡面會有很多的細節資訊。
   SNAP_ID       DBID INSTANCE_NUMBER RESOURCE_NAME                  CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_AL LIMIT_VALU
---------- ---------- --------------- ------------------------------ ------------------- --------------- ---------- ----------
     21032 3100077577               1 processes                                     3731            6813       9000       9000
     21032 3100077577               1 sessions                                      3712            6816      13560      13560
     21032 3100077577               1 enqueue_locks                                 3936            7081     154180     154180
     21032 3100077577               1 max_rollback_segments                          405             408      14916      65535
     21032 3100077577               1 parallel_max_servers                            62             182        180       3600
     21033 3100077577               1 processes                                     3679            6813       9000       9000
     21033 3100077577               1 sessions                                      3673            6816      13560      13560
     21033 3100077577               1 enqueue_locks                                 3861            7081     154180     154180
     21033 3100077577               1 max_rollback_segments                          405             408      14916      65535
     21033 3100077577               1 parallel_max_servers                            46             182        180       3600

session數和報告中還是有略微的差別。但是差別幅度很小。
讓人意外的是，我們還可以檢視到process,並行資源的情況。
如果需要得到一個session數的統計結果，這個問題就很有幫助。