Oracle 10g自动工作负载信息库

Oracle Database 10g 提供了一个显著改进的工具：自动工作负载信息库 (AWR)。AWR 和数据库一起安装，不但采集统计数据，还采集导出的量度。

快速测试驱动程序

通过运行 $ORACLE_HOME/rdbms/admin 目录中的 awrrpt.sql 脚本，AWR 的功能可以立即通过它从采集的统计数据和量度中生成的报表得到最好的说明。这个脚本从外观和感觉上类似于 Statspack，它显示所有的现有 AWR 快照并请求两个特定的快照作为时间间隔边界。它产生两种类型的输出：文本格式（类似于 Statspack 报表的文本格式但来自于 AWR 信息库）和默认的 HTML 格式（拥有到部分和子部分的所有超链接），从而提供了非常用户友好的报表。现在运行该脚本以查看报表，从而对 AWR 的功能有一个了解。

实施

现在，让我们来看看 AWR 是如何设计和构建的。AWR 实质上是一个 Oracle 的内置工具，它采集与性能相关的统计数据，并从那些统计数据中导出性能量度，以跟踪潜在的问题。与 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 分钟，保留时间为两天 — 您可以发出以下命令。参数以分钟为单位。

　
begin
　 dbms_workload_repository.modify_snapshot_settings (
　interval => 20,
　retention => 2*24*60
　 );
end;

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 采集到的重要的量度、它们所属的组和采集它们的单位。例如，下面是一个记录（竖直格式）：

　
DBID　: 4133493568
GROUP_ID　: 2
GROUP_NAME: System Metrics Long Duration
METRIC_ID : 2075
METRIC_NAME　 : CPU Usage Per Sec
METRIC_UNIT　 : CentiSeconds Per Second

它显示一个量度“每秒 CPU 使用率”以“每秒的厘秒数”为单位进行测量，并且该量度属于一个量度组 “System Metrics Long Duration”。这条记录可以和其它的表（如 DBA_HIST_SYSMETRIC_SUMMARY）结合，以获得数据库的活动信息，形式如下：

select begin_time, intsize, num_interval, minval, maxval,
    average, standard_deviation sd 
from dba_hist_sysmetric_summary where metric_id = 2075;

BEGININTSIZE NUM_INTERVAL　 MINVAL　MAXVAL　AVERAGE　 SD
----- ---------- ------------　 ------- ------- --------　----------
11:39 179916　 30 0　333　9.81553548
11:09 180023　 3021　35　 28　5.91543912

... and so on ...

下面我们看看 CPU 时间是如何消耗的（以厘秒为单位）。标准差加入到了我们的分析中，它有助于确定平均数字是否反映了实际的工作负载。在第一条记录中，平均值是每秒消耗 CPU 时间 3 厘秒，但标准差是 9.81，这意味着平均值 3 不能反映工作负载。在第二个例子中，平均值为 28，标准差为 5.9，这更具有代表性。这种类型的信息趋势有助于了解几个环境参数对性能量度的影响。

使用统计数据

迄今为止，我们看到了 AWR 所采集的内容，现在让我们看看它将如何处理数据。

大多数性能问题并不是孤立存在的，而留有指示性的迹象，这些迹象将通向问题最终的根源。让我们使用一个典型的调整实践来说明这一点：您注意到系统很慢，于是决定查看等待的原因。您检查发现“缓冲区忙等待”非常高。问题可能出在哪里呢？有几种可能：可能有一个单调增加的索引，可能一个表太满了，以至于要求将单个数据块非常快速地加载到内存中，或其它一些因素。无论在哪种情况下，您都首先要确定存在问题的段。如果它是一个索引段，那么您可以决定重新构建它，把它修改为一个反向键索引，或把它转换成一个在 Oracle Database 10g 中引进的散列分区索引。如果它是一个表，您可以考虑修改存储参数来使它不那么密集，或者利用自动段空间管理把它转移到一个表空间中。

您的处理计划一般是有规律的，并且通常基于您对各种事件的了解和您处理它们的经验。现在设想相同的事情由一个引擎来完成，这个引擎采集量度并根据预先确定的逻辑来推出可能的计划。您的工作不就变得更轻松了吗？

现在在 Oracle Database 10g 中推出的这个引擎称为自动数据库诊断监控程序 (ADDM)。为了作出决策，ADDM 使用了由 AWR 采集的数据。在上面的讨论中，ADDM 可以看到发生了缓冲区忙等待，然后取出相应的数据来查看发生缓冲区忙等待的段，评估其特性和成分，最后为数据库管理员提供解决方案。在 AWR 进行的每一次快照采集之后，调用 ADDM 来检查量度并生成建议。因此，实际上您拥有了一个一天二十四小时工作的自动数据库管理员，它主动地分析数据并生成建议，从而把您解放出来，使您能够关注更具有战略意义的问题。

要查看 ADDM 建议和 AWR 信息库数据，请使用在名称为 DB Home 的页面上的新的 Enterprise Manager 10g 控制台。要查看 AWR 报表，您可以从管理转至工作负载信息库，然后转至 Snapshots 来查看它们。在以后的部分中，我们将更详细地讨论 ADDM。

您还可以指定根据特定的情况来生成警报。这些警报称为服务器生成警报，它们被推送到高级队列中，在其中它们可以被任意监听它的客户端使用。一个这样的客户端是 Enterprise Manager 10g，在其中警报被突出显示。

时间模型

当您有性能问题时，要缩短响应时间您最先想到的是什么？很明显，您希望消除（或减少）增加时间的因素的根源。您如何知道时间花费在哪里 — 不是等待，而是真正在进行工作？

Oracle Database 10g 引进了时间模型，以确定在各个地方花费的时间。花费的总的系统时间记录在视图 V$SYS_TIME_MODEL 中。下面是查询和输出结果。

STAT_NAME VALUE
------------------------------------- --------------
DB time　 58211645
DB CPU54500000
background cpu time　 254490000
sequence load elapsed time0
parse time elapsed1867816
hard parse elapsed time　 1758922
sql execute elapsed time　57632352
connection management call elapsed time　 288819
failed parse elapsed time 50794
hard parse (sharing criteria) elapsed time220345
hard parse (bind mismatch) elapsed time　 5040
PL/SQL execution elapsed time 197792
inbound PL/SQL rpc elapsed time　 0
PL/SQL compilation elapsed time　

 活动会话历史
视图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()来删除这些基准线，而快照还是会被保留。同样的，当清除规则需要清除掉旧的快照信息时，与这些旧快照信息相关的基准线不会被清除，以便于以后的进一步深入分析。