作者:dbtan |【转载时请以超链接形式标明文章出处作者信息】


自动负载信息库:AWR的引入
内存中记录的ASH信息始终是有限的,为了保存历史数据,这些信息最终需要写入磁盘。这些历史信息的存储,引出了Oracle 10g的另外一个新特性:自动负载信息库(Automatic Workload Repository,AWR)

1. AWR的采样机制:
AWR收集关于该特定数据库的操作统计信息和其他统计信息,Oracle以固定的时间间隔(默认为每小时一次)为其所有重要统计信息和负载信息执行一次快照,并将这些快照存储在AWR中。这些信息在AWR中保留给定的时间(默认为一周),然后被清除。执行快照的频率及其保持时间都可以自定义,以满足不同环境的独特需要。

AWR的采样工作由后台进程MMON每60分钟执行一次,ASH信息同样会被采样写出到AWR负载库。虽然ASH Buffers被设计为保留1小时的信息,但是很多时候这个内存是不足够的,当ASH Buffers写满之后,另外一个后台进程MMNL将会主动将ASH信息写出。由于数据量巨大,把所有的ASH数据写到磁盘上是不可接受的。一般是在写到磁盘的时候过滤这个数据,写出的数据占采样数据的10%,写出时通过direct-path insert完成,尽量减少日志生成,从而最小化数据库性能影响。

通过下图可以理解一下ASH与AWR的关系。

ASH与AWR的关系

AWR的行为受到数据库另外一个重要初始化参数STATISTICS_LEVEL的影响,该参数有3个可选值。
·BASIC:设置为BASIC时,AWR的统计信息收集所有自我调整的特性都被关闭。
·TYPICAL:设置为TYPICAL时,数据库收集部分统计信息,这些信息为典型的数据库监控需要,是数据库的缺省设置。
·ALL:所有可能的统计信息都被收集。

ASH信息的写出比例受一个隐含参数控制:

sys@CCDB> @GetHidPar.sql  
Enter value for par: filter_ratio
old   4: AND x.ksppinm LIKE '%&par%'
new   4: AND x.ksppinm LIKE '%filter_ratio%'
NAME                           VALUE                DESCRIB
------------------------------ -------------------- ------------------------------------------------------------
_ash_disk_filter_ratio         10                   Ratio of the number of in-memory samples to the number of sa
                                                    mples actually written to disk

写出到AWR负载库的ASH信息记录在AWR的基础表wrh$_active_session_history中,wrh$_active_session_history是一个分区表,Oracle会自动进行数据清理。

wrh$_active_session_history记录的这些历史信息,可以通过dba_hist_active_sess_history视图进行聚合查询,通过简化后的下图来看一下Oracle以session为起点的一系列用以追踪和诊断的数据库对象。

一系列用以追踪和诊断的数据库对象

简单总结一下:
·v$session代表数据库活动的开始,是为源起;
·v$session_wait视图用以实时记录活动session的等待情况,是当前信息;
·v$session_wait_history是对v$session_wait的简单增强,记录活动session的最近10次等待;
·v$active_session_history是ASH的核心,用以记录活动session的历史等待信息,每秒采样1次,这部分内容记录在内存中,期望值是记录1个小时的内容;
·wrh$_active_session_history是v$active_session_history在AWR的存储池,v$active_session_history中记录的信息会被定期(每小时1次)地刷新到负载库中,并缺省保留一个星期用于分析;
·dba_hist_active_sess_history视图是wrh$_active_session_history视图和其他几个视图的联合展现,我们通常通过这个视图进行历史数据的访问。

通过以上分析过程可以看到,关于session信息的记录,Oracle从不同的粒度进行了增强,目的只有一个,那就是全面真实地记录、监控和反映数据库的运行状况。

2. AWR的采样数据存储:
AWR记录的信息还远不止于此,通过系统的自动采样,AWR可以收集数据库运行的各方面统计信息及等待等重要数据,提供给数据库诊断分析使用。当然AWR的信息需要独立存储,在Oracle 10g中,新增的SYSAUX表空间是这类信息的存储地:

sys@CCDB> select occupant_name,occupant_desc,schema_name,space_usage_kbytes/1024 "MB"
  2  from v$sysaux_occupants
  3  where occupant_name like '%AWR%';
OCCUPANT_NAME   OCCUPANT_DESC                                           SCHEMA_NAME             MB
--------------- ------------------------------------------------------- --------------- ----------
SM/AWR          Server Manageability - Automatic Workload Repository    SYS               161.8125

在Oracle 10g之前的版本中,类似的功能是由Statspack实现,但是Statspack需要由用户自行安装调度,并且其收集的信息十分有限。我们一直提到的session历史信息Statspack就是无法提供的。AWR大大强化了这部分信息,由于AWR收集的信息十分完备,所以经常被称为“数据库的数据仓库”。

AWR收集的信息通过一系列的视图展现出来,可以查询这些视图获得数据库的信息采样:

sys@CCDB> select object_name,object_type from dba_objects            
  2  where object_name like 'DBA_HIST%' and object_type = 'VIEW' and rownum < 5;
OBJECT_NAME                    OBJECT_TYPE
------------------------------ -------------------
DBA_HIST_DATABASE_INSTANCE     VIEW
DBA_HIST_SNAPSHOT              VIEW
DBA_HIST_SNAP_ERROR            VIEW
DBA_HIST_COLORED_SQL           VIEW

这些系统视图的底层表大政有3类WRM$表存储AWR的元数据(Workload Repository Metadata),WRH$表存储采样快照的历史数据(Workload Repository Historical),WRI$表存储同数据库建议功能相关的数据。Oracle 11g中相关表的数量大致如下:

sys@CCDB> select * from v$version where rownum<2;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
sys@CCDB> select substr(table_name,1,4),count(*) from dba_tables
  2  where table_name like 'WR%'
  3  group by substr(table_name,1,4);
SUBSTR(TABLE_NAME,1,4)           COUNT(*)
------------------------------ ----------
WRM$                                    8
WRH$                                  113
WRR$                                    9
WRI$                                   86

从Oracle 11g开始,这个家族又增加了新的成员,WRR$类表代表的是Oracle 11g新功能Workload Capture以及Workload Replay相关信息:

sys@CCDB> select table_name from dba_tables where table_name like 'WRR%';
TABLE_NAME
-----------------------------------
WRR$_REPLAY_STATS
WRR$_REPLAY_DIVERGENCE
WRR$_REPLAYS
WRR$_FILTERS
WRR$_CONNECTION_MAP
WRR$_CAPTURE_STATS
WRR$_CAPTURES
WRR$_REPLAY_SEQ_DATA
WRR$_REPLAY_SCN_ORDER
9 rows selected.

AWR的历史数据表主要通过分区表进行存储,这些分区表信息可以通过dba_tab_partitions视图进行查询:

sys@CCDB> select table_name,partition_name,tablespace_name
  2  from dba_tab_partitions
  3  where table_name like 'WR%' and rownum <5;
TABLE_NAME           PARTITION_NAME                 TABLESPACE_NAME
-------------------- ------------------------------ ------------------
WRH$_FILESTATXS      WRH$_FILESTATXS_MXDB_MXSN      SYSAUX
WRH$_SQLSTAT         WRH$_SQLSTAT_MXDB_MXSN         SYSAUX
WRH$_WAITSTAT        WRH$_WAITSTAT_MXDB_MXSN        SYSAUX
WRH$_LATCH           WRH$_LATCH_MXDB_MXSN           SYSAUX

3. AWR报告展现:
AWR记录的数据可以通过报告来展现,报告可以通过运行脚本生成类似Statspack report的AWR报告,生成报告的脚本位于$ORACLE_HOME/rdbms/admin/awrrpt.sql,报表可以通过两种形式输出:TEXT和HTML。用脚本生成AWR报告的过程与生成Statspack报告非常类似,需要以sys用户执行这个脚本,执行过程需要选择报表类型、天数(用来决定显示那几天的snapshot)、begin_snap、end_snap以及报表名称等5个参数。

以下是一个HTML格式报表的展现示例,如下图。

一个HTML格式的AWR报表 

值得注意的是,从Oracle 11g开始,AWR报告中增加了很多和操作系统相关的信息,这些信息此前无法通过报告获取。新增的内容包括主机CPU和内存信息:

Host Name        Platform                         CPUs Cores Sockets Memory(GB)
---------------- -------------------------------- ---- ----- ------- ----------
test7            Linux 64-bit for AMD                4     2       2       1.96

负载概要信息增加了CPU信息:

Load Profile              Per Second    Per Transaction   Per Exec   Per Call
~~~~~~~~~~~~         ---------------    --------------- ---------- ----------
      DB Time(s):                0.0                0.0       0.00       0.01
       DB CPU(s):                0.0                0.0       0.00       0.02
       Redo size:            1,450.6            9,309.5
   Logical reads:               28.8              185.1
   Block changes:                9.1               58.1
  Physical reads:                0.2                1.2
Physical writes:                0.4                2.6
      User calls:                0.1                0.8
          Parses:                1.5                9.9
     Hard parses:                0.0                0.1
W/A MB processed:           62,833.8          403,253.5
          Logons:                0.0                0.3
        Executes:                2.8               18.0
       Rollbacks:                0.0                0.0
    Transactions:                0.2

以及CPU负载信息、实例CPU耗用以及内存使用等信息:

Host CPU (CPUs:    4 Cores:    2 Sockets:    2)
~~~~~~~~         Load Average
               Begin       End     %User   %System      %WIO     %Idle
           --------- --------- --------- --------- --------- ---------
                0.16      0.11       0.2       0.1       0.4      99.8
Instance CPU
~~~~~~~~~~~~
              % of total CPU for Instance:   0.1
              % of busy  CPU for Instance:  41.2
  %DB time waiting for CPU - Resource Mgr:   0.0

Memory Statistics
~~~~~~~~~~~~~~~~~                       Begin          End
                  Host Mem (MB):      2,011.0      2,011.0
                   SGA use (MB):        604.0        604.0
                   PGA use (MB):        104.8        107.0
    % Host Mem used for SGA+PGA:        35.24        35.24

4. AWR比较报告诊断案例:
值得一提的是AWR报告还有另外一种形式的展现,那就是AWR比较报告。通常生成AWR报告的脚本是awrrpt.sql,而比较报告可以通过awrddrpt.sql生成(这个脚本通过调用awrddrpi.sql脚本生成报告)。这个脚本生成报告的过程与awrrpt.sql有所不同。

运行这个脚本,可以选择HTML格式生成报告:

sys@CCDB> @?/rdbms/admin/awrddrpt.sql
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type: html

Type Specified:                  html

接下来列出数据库的DBID等信息,接下来定义了报告数据库的DBID和实例号:

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   DB Id     Inst Num DB Name      Instance     Host
------------ -------- ------------ ------------ ------------
* 3313878466        1 CCDB         ccdb         test7
* 3313878466        1 CCDB         ccdb         localhost.lo
                                                caldomain

Database Id and Instance Number for the First Pair of Snapshots
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using 3313878466 for Database Id for the first pair of snapshots
Using          1 for Instance Number for the first pair of snapshots

接下来选择列出采样的时间,缺省列出全部:

Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed.  Pressing <return> without
specifying a number lists all completed snapshots.

Enter value for num_days:

Listing all Completed Snapshots

                                                        Snap
Instance     DB Name        Snap Id    Snap Started    Level
------------ ------------ --------- ------------------ -----
ccdb         CCDB              7272 07 Mar 2010 09:00      1
                               7273 07 Mar 2010 10:00      1
                               7274 07 Mar 2010 11:00      1
......
                               7474 15 Mar 2010 19:00      1
                               7475 15 Mar 2010 20:00      1
                               7476 15 Mar 2010 21:00      1

注意接下来提示与以往的不同,这里提示定义第一对起始和结束的快照ID,这里选择问题时段的7407~7430时段:

Specify the First Pair of Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 7407
First Begin Snapshot Id specified: 7407

Enter value for end_snap: 7430
First End   Snapshot Id specified: 7430

接下来是和之前类似的过程,再次列出实例信息:

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   DB Id     Inst Num DB Name      Instance     Host
------------ -------- ------------ ------------ ------------
* 3313878466        1 CCDB         ccdb         test7
* 3313878466        1 CCDB         ccdb         localhost.lo
                                                caldomain

Database Id and Instance Number for the Second Pair of Snapshots
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using 3313878466 for Database Id for the second pair of snapshots
Using          1 for Instance Number for the second pair of snapshots

接下来同样列采样数据:

Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed.  Pressing <return> without
specifying a number lists all completed snapshots.

Enter value for num_days2: 
Listing all Completed Snapshots

                                                        Snap
Instance     DB Name        Snap Id    Snap Started    Level
------------ ------------ --------- ------------------ -----
ccdb         CCDB              7272 07 Mar 2010 09:00      1
                               7273 07 Mar 2010 10:00      1
                               7274 07 Mar 2010 11:00      1
......
                               7474 15 Mar 2010 19:00      1
                               7475 15 Mar 2010 20:00      1
                               7476 15 Mar 2010 21:00      1

这里定义与之前不同的采样时段,选择7431~7454时段:

Specify the Second Pair of Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap2: 7431
Second Begin Snapshot Id specified: 7431

Enter value for end_snap2: 7454
Second End   Snapshot Id specified: 7454

最后定义输出报告名称,缺省的以awrdiff开头,也就是AWR报告对比之意:

Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrdiff_1_7407_1_7431.html  To use this name,
press <return> to continue, otherwise enter an alternative.

Enter value for report_name:

Using the report name awrdiff_1_7407_1_7431.html

现在看看这个生成的报告与普通报告的不同,首先第一部分题目显示“WORKLOAD REPOSITORY COMPARE PERIOD REPORT”,表示这是一个不同阶段的比较报告,第一个报告以及第二个报告的相关信息会对比列出,便于比较,如下图。

AWR对比报告

负载概要信息部分通过对比各类统计数据,可以直观地告诉我们不同时段数据库性能的变化。

为了能够通过比较机制对数据库不同阶段的性能情况进行比较,可以为AWR创建基线(Base Line),创建的基线不会被清除,以后生成的采样数据或者优化后采样可以保留的基线进行对比,以确定数据库的性能变化。创建Base Line可以通过Database Control进行,也可以通过命令完成,在内部都是通过DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE来完成Base Line的创建。

创建的Base Line可以通过数据字典视图dba_hist_baseline查询。类似以前的Statspack,Oracle允许将AWR数据导出并迁移到其他数据库以便于以后分析。Oracle 10gR2提供了新工具来完成导出和迁移AWR数据的工作。

DBMS_SWRF_INTERNAL.AWR_EXTRACT可以用来导出数据,awrextr.sql脚本就是用来完成这个工作的,而导入工作可以通过DBMS_SWRF_INTERNAL包中的AWR_LOAD和MOVE_TO_AWR过程来完成。awrload.sql脚本用于完成这个工作。

5. AWR使用信息报告:
Oracle还随软件提供一个脚本用于输出AWR的使用信息,这个脚本是awrinfo.sql,运行这个脚本,将会输出AWR的空间使用、快照采样、ASH及ADDM等AWR元数据信息。输出显示为3类:
·AWR Snapshot Info Gathering;
·Advisor Framework Diagnostics;
·AWR and ASH Usage Info Gathering。

下面是运行这个脚本的输出的摘要示例:

sys@CCDB> @?/rdbms/admin/awrinfo.sql
~~~~~~~~~~~~~~~
AWR INFO Report
~~~~~~~~~~~~~~~

Report generated at
22:13:44 on Mar 15, 2010 ( Monday ) in Timezone +08:00

Warning: Non Default AWR Setting!
--------------------------------------------------------------------------------
Snapshot interval is 60 minutes and Retention is 8 days

       DB_ID DB_NAME   HOST_PLATFORM                             INST STARTUP_TIME      LAST_ASH_SID PAR
------------ --------- ---------------------------------------- ----- ----------------- ------------ ---
* 3313878466 CCDB      test7 - Linux 64-bit for AMD                 1 16:32:20 (01/26)      26804860 NO

########################################################
(I) AWR Snapshots Information
########################################################

*****************************************************
(1a) SYSAUX usage - Schema breakdown (dba_segments)
*****************************************************
|
| Total SYSAUX size                        901.9 MB ( 3% of 32,768.0 MB MAX with AUTOEXTEND ON )
|
| Schema  SYS          occupies            424.3 MB (  47.0% )
| Schema  SYSMAN       occupies            145.3 MB (  16.1% )
| Schema  FLOWS_030000 occupies            105.6 MB (  11.7% )
| Schema  XDB          occupies             97.1 MB (  10.8% )
| Schema  MDSYS        occupies             54.5 MB (   6.0% )
| Schema  OLAPSYS      occupies             15.6 MB (   1.7% )
......
**********************************
(3b) Space usage within AWR Components (> 500K)
**********************************

COMPONENT        MB SEGMENT_NAME - % SPACE_USED                                           SEGMENT_TYPE
--------- --------- --------------------------------------------------------------------- ---------------
FIXED          16.0 WRH$_SYSMETRIC_HISTORY                                        -  83%  TABLE
FIXED          12.0 WRH$_SYSMETRIC_HISTORY_INDEX                                  -  83%  INDEX
FIXED           3.0 WRH$_SYSMETRIC_SUMMARY                                        -  82%  TABLE
FIXED           2.0 WRH$_WAITCLASSMETRIC_HIST_IND                                 -  38%  INDEX
FIXED           2.0 WRH$_WAITCLASSMETRIC_HISTORY                                  -  58%  TABLE
FIXED           2.0 WRH$_SYSMETRIC_SUMMARY_INDEX                                  -  54%  INDEX
FIXED           1.0 WRH$_LATCH.WRH$_LATCH_3313878466_7264                         -  88%  TABLE PARTITION
FIXED           0.9 WRH$_SESSMETRIC_HISTORY_INDEX                                 -  12%  INDEX
FIXED           0.7 WRH$_LATCH.WRH$_LATCH_3313878466_7298                         -  90%  TABLE PARTITION
FIXED           0.7 WRH$_LATCH.WRH$_LATCH_3313878466_7322                         -  90%  TABLE PARTITION

4. 自动数据库诊断监控:ADDM的引入
有了这个AWR这个“数据仓库”之后,Oracle自然可以在此基础之上实现更高级别的智能应用,更大程度地发挥AWR的信用,这就是Oracle 10g引入的另外一个功能自动数据库诊断监控程序(Automatic Database Diagnostic Monitor,ADDM),通过ADDM,Oracle试图使数据库的维护、管理和优化工作变得更加自动和简单。

ADDM可以定期检查数据库的状态,根据内建的专家系统,自动确定潜在的数据库性能瓶颈,并提供调整措施和建议。由于这一切都是内建在Oracle数据库系统之内的,其执行效率很高,几乎不影响数据库的总体性能。

新版的Database Control可以以一种方便直观的形式提供ADDM的结果和建议,并引导管理员逐步实施ADDM的建议,快速解决性能问题。

通过下图可以直观看到AWR及ADDM的关系。

AWR及ADDM的关系

对于ADDM,不在本文做过多详细介绍了。

- The End -