使用awr来分析sesson leak问题(r3笔记第78天)

时间:2022-05-04
本文章向大家介绍使用awr来分析sesson leak问题(r3笔记第78天),主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

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