使用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数的统计结果,这个问题就很有帮助。

上一篇:nginx部署多个静态页面


下一篇:如何选择阿里云服务器配置