Oracle中的ASH,AWR及ADDM

ASH以V$SESSION为基础，每秒采样一次，记录活动会话等待的事件。不活动的会话不会采样，采样工作由新引入的后台进程MMNL来完成。ASH buffers 的最小值为1MB,最大值不超过30MB。内存中记录数据。期望值是记录一小时的内容。
生成ASH报告：
SQLPLUS>@?/rdbms/ashrpt.sql
ASH 内存记录数据始终是有限的，为了保存历史数据，引入了自动负载信息库(Automatic Workload Repository ,AWR) 由后台进程MMON完成。ASH信息同样被采集写出到AWR负载库中。由于内存不是足够的，所以MMNL进程在ASH写满后会将信息写出到AWR负载库 中。ASH全部写出是不可接受的，所以一般只写入收集的10%的数据量，而且使用direct-path insert完成，尽量减少日志的生成，从而最小化性能影响。 写出到AWR负载库的ASH信息记录在AWR的基础表wrh$active_session_hist中，wrh$active_session_hist是一个分区表，Oracle会自动进行数据清理。

运行 $ORACLE_HOME/rdbms/admin 目录中的 awrrpt.sql 脚本，AWR 的功能可以立即通过它从采集的统计数据和量度中生成的报表得到最好的说明。与 Statspack 不同，快照由一个称为 MMON 的新的后台进程及其从进程自动地每小时采集一次。为了节省空间，采集的数据在 7 天后自动清除。快照频率和保留时间都可以由用户修改。
要查看当前的设置，您可以使用下面的语句：
select snap_interval, retention from dba_hist_wr_control;
    SNAP_INTERVAL       RETENTION
-------------------   -------------------
+00000 01:00:00.0      +00007 00:00:00.0
这些 SQL 语句显示快照每小时采集一次，采集的数据保留 7 天。要修改设置 — 例如，快照时间间隔为 20 分钟，保留时间为两天 — 您可以发出以下命令。参数以分钟为单位。
  exec dbms_workload_repository.modify_snapshot_settings ( interval => 20, retention => 2*24*60 );

AWR 使用几个表来存储采集的统计数据，所有的表都存储在新的名称为 SYSAUX 的特定表空间中的 SYS 模式下，并且以 WRM$_* 和 WRH$_* 的格式命名。前一种类型存储元数据信息（如检查的数据库和采集的快照），后一种类型保存实际采集的统计数据。（您可能已经猜到，H 代表“历史数据 (historical)”而 M 代表“元数据 (metadata)”。）在这些表上构建了几种带前缀 DBA_HIST_ 的视图，这些视图可以用来编写您自己的性能诊断工具。视图的名称直接与表相关；例如，视图 DBA_HIST_SYSMETRIC_SUMMARY 是在WRH$_SYSMETRIC_SUMMARY 表上构建的。

AWR 历史表采集的信息比 Statspack 多许多，这些信息包括表空间使用率、文件系统使用率、甚至操作系统统计数据。这些表的完整的列表可以通过以下命令从数据字典中看到：

select view_name from user_views where view_name like 'DBA\_HIST\_%' escape '\';

视图 DBA_HIST_METRIC_NAME 定义 AWR 采集到的重要的量度、它们所属的组和采集它们的单位。与DBA_HIST_SYSMETRIC_SUMMARY结合，以获得数据库的活动信息.

Oracle Database 10g 中推出自动数据库诊断监控程序 (ADDM)。为了作出决策，ADDM 使用了由 AWR 采集的数据. Oracle Database 10g 引进了时间模型，以确定在各个地方花费的时间。花费的总的系统时间记录在视图 V$SYS_TIME_MODEL 中。

要找出有多少个会话在等待某些事件，您可以使用下面的命令
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 的额外的列也将帮助您实现这一目的。例如，如果会话等待的事件之一是缓冲区忙等待，那么正确的诊断必须指出发生等待事件的段。您可以从 ASH 视图列 CURRENT_OBJ# 中获得这一信息，然后该列可以和 DBA_OBJECTS 结合，以获得存在问题的段。 ASH 还记录并行查询服务器会话，这对诊断并行查询等待事件非常有用。如果记录是针对一个并行查询从属进程，那么协调服务器会话的 SID 由 QC_SESSION_ID 列指定。列 SQL_ID 记录产生等待事件的 SQL 语句的 ID，该列可以和 V$SQL 视图结合，以获取存在问题的 SQL 语句。为了方便一个共享用户环境（如 web 应用程序）中的客户端的识别，也显示了 CLIENT_ID 列，这可以由 DBMS_SESSION.SET_IDENTIFIER 来设置。 既然 ASH 信息这么有价值，那么如果以一种类似于 AWR 的永久方式来保存这种信息不是很好吗？幸运的是，它是以这种方式来进行保存的；由 MMON 从进程将信息刷新到 AWR 表中，从而保存在磁盘上，并且信息可以通过视图 DBA_HIST_ACTIVE_SESS_HISTORY 来查看。 人工采集快照默认是自动采集的，但您也可以按需要采集它们。所有的 AWR 功能都在程序包 DBMS_WORKLOAD_REPOSITORY 中实施。要采集一次快照，只需发出下面的命令：
execute 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 编号，作为上面指定的基准线的一部分。查看现有的基准线：
 select * from dba_hist_baseline;
在一些调整步骤之后，我们可以创建另一个基准线 假设名称为 apply_interest_2，然后只为那些与这两条基准线相关的快照比较量度。像这样把快照分隔在仅仅几个集合中有助于研究调整对于性能量度的影响。您可以在分析之后使用 drop_baseline() 来删除基准线；快照将保留。此外，当清除例程开始删除旧的快照时，与基准线相关的快照不会被清除，从而允许进行进一步的分析。

@?/rdbms/admin/awrrpt
@?/rdbms/admin/addmrpt
@?/rdbms/admin/awrsqrpi (查看具体SQL的执行计划)

v$session                                      (当前正在发生)
v$session_wait                            (当前正在发生)
v$session_wait_history              (会话最近的10次等待事件)
v$active_session_history           (内存中的ASH采集信息，理论为1小时)
wrh$_active_session_history    (写入AWR库中的ASH信息，理论为1小时以上)
dba_hist_active_sess_history   (根据wrh$_active_session_history生成的视图)