视图V$SESSION在oracle 10G中被增强了，其中最有价值的一项增强就是包括了等待时间和他们持续的时间，而不需要通过V$SESSION_WAIT来查看了。然而，因为这个视图很少反映出真实的时间值，所以一些重要信息就丢失了。例如，如果你从这个视图中查询看是否存在某个会话在等待某个非空闲的事件，而如果这个事件的数据存在问题，你将无法找到你想要的东西，因为等待事件必须依赖于你所查询到的时间数据。Oracle 10G的另一个特性活动会话历史（Active Session History ASH）和AWR类似，将会话的性能统计数据存储在一个缓存中以便于将来的分析。但是，和AWR不一样的是，这些数据的存储并非永久的存储在表当中，而是存在内存当中，可以通过视图V$ACTIVE_SESSION_HISTORY来查到。这些数据每秒中被收集一次，并且只有哪些活动的会话才会被收集。随着时间的推进，老的数据被移出、新的数据被收集到内存，如此循环。为了找到有多少会话在等待某些事件，可以使用以下脚本：
select session_id||','||session_serial# SID, n.name, wait_time, time_waited from v$active_session_history a, v$event_name n where n.event# = a.event#
这条语句的执行结果可以显示出事件的名称和花费了多少事件等待。增加ASH的字段可以帮你对某个特定的等待事件进行深入定位。例如，如果这些会话等待的事件中有一个是buffer busy wait，那就必须再做适当的诊断来定位是在哪个段上发生了等待事件。你可以通过将ASH视图中的CURRENT_OBJ#字段与DBA_OBJECTS连接查询来查到发生问题的段。
ASH还记录了并行查询服务的会话信息，这些信息对于诊断并行查询的等待事件很有用。如果记录的是并行查询的从进程的信息，协同服务会话的SID会被表示在QC_SESSION_ID字段中。字段SQL_ID记录了产生等待事件的SQL语句的ID，通过将它与视图V$SQL联合查询，可以找出这个令人讨厌的SQL语句。CLIENT_ID可以使在如web应用这样的共享用户环境中更容易定位是哪个客户端，这个字段可以通过存储过程DBMS_SESSION.SET_IDENTIFIER来设置。
既然ASH的信息如此有价值，那么不是把它的数据像AWR一样永久的存储起来不是更好吗？MMON进程会将这些信息存储到磁盘以服务于AWR表，并且可以通过视图DBA_HIST_ACTIVE_SESS_HISTORY来查询。
手工收集
在默认情况下，这些快照信息是自动收集的。但是你也可以随时手工收集。所有的AWR的功能都可以通过包DBMS_WORKLOAD_REPOSITORY来实现。要产生一个快照，只要执行：exec dbms_workload_repository.create_snapshot就可以了。
这样会立即产生一个快照记录在表WRM$_SNAPSHOT中，并且在典型（TYPICAL）级别上收集度量数据。如果需要收集更细的统计数据，可以在上述存储过程执行时设定参数FLUSH_LEVEL为ALL。统计数据的删除也是自动的，但也可以通过执行存储过程drop_snapshot_range()来手工删除。
基准线
一个典型的性能调优过程时从收集一个度量数据集的基准线开始，然后调整，再收集另一个基准线集。通过比较这两个基准数据集来观察调整产生的效果。在AWR中，可以通过已经存在的多个快照做处理来进行类似的推理。假设一个名叫apply_interest的显著产生性能压力的进程在下午1：00到3：00之间运行，相应的快照ID是从56到59，我们可以用以下存储过程为这些快照定一个名叫apply_interest_1的基准线：
exec dbms_workload_repository.create_baseline(56,59,’apply_interest_1’);
这一操作标识了从56到59的快照作为名为“apply_interest_1”的基准线的一部分。
用以下语句检查已经存在的基准线：
SQL> select * from dba_hist_baseline; DBID BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID ---------- ----------- -------------------- ------------- ----------- 4133493568 1 apply_interest_1 56 59
经过一些调优步骤，我们再创建另外一个基准线，名叫“apply_interest_2”，并比较与仅与两个基准线相关的快照的度量数据。像这样将一些快照独立成这样一些基准线能帮助了解性能调优产生的效果。分析完毕后，可以通过调用存储过程drop_baselin()来删除这些基准线，而快照还是会被保留。同样的，当清除规则需要清除掉旧的快照信息时，与这些旧快照信息相关的基准线不会被清除，以便于以后的进一步深入分析。
