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数的统计结果，这个问题就很有帮助。 来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1361048/，如需转载，请注明出处，否则将追究法律责任。