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情况，如果没有第三方的工具，通过数据库来查询是基本没有办法的。
我们可以从下面的报告中得到一些思路。
在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数的统计结果，这个问题就很有帮助。
对于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数的统计结果，这个问题就很有帮助。
