AWR ADDM

AWR (auto workload repository),本篇限介绍如何使用，关于统计信息可自行研究，对于statspack，不作介绍。
awr属于sys用户，收集信息存储在SYSAUX表空间。
有三类表：
wri$-(i:internal 内部)-
wrm$-(m:metadata 元数据)-
wrh$-（h:histroy 历史)-
我们从视图中查到的所有信息都是来自以上的表:
dba_hist_wr_control视图创建：
create or replace view dba_hist_wr_control as
select dbid, snap_interval, retention,
       decode(topnsql, 2000000000, 'DEFAULT',
                       2000000001, 'MAXIMUM',
                       to_char(topnsql, '999999999')) topnsql
from WRM$_WR_CONTROL;     =>来自表WRM$
comment on table DBA_HIST_WR_CONTROL is 'Workload Repository Control Information';
SQL> select * from dba_hist_wr_control;


      DBI               SNAP_INTERVAL           RETENTION                   TOPNSQL
3848072073       +00000 01:00:00.0     +00008 00:00:00.0          DEFAULT

AWR每一小时创建一次快照 ，保存8天 。
以上的时间我们可以修改，通过oracle给我们提供的一个包 ：
sys.dbms_workload_repository
里面有很多过程：
purge_sql_details
create_baseline_template
create_snapshot
drop_snapshot_range
modify_snapshot_settings
create_baseline
drop_baseline(基线）
.......
通过修改 modify_snapshot_settings里的 参数:

INTERVAL           RETENTION 参数的值是分钟
SQL> execute dbms_workload_repository.modify_snapshot_settings(interval=>40);


PL/SQL 过程已成功完成。

把执行快照时间改为40分钟一次：
SQL>  select * from dba_hist_wr_control;


      DBID SNAP_INTERVAL                                                              RETENTION                                                            TOPNSQL
---------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
3848072073 +00000 00:40:00.0                                                          +00008 00:00:00.0                                                    DEFAULT

oracle每一小时创建一个快照，收集了数据库很多信息，内容量十分丰富，我们可以手动创建快照，仍然用到 sys.dbms_workload_repository，里面有过程create_snapshot.
select * from dba_hist_snapshot;

数据库现在总共创了52个快照。
dba_hist_baseline，  dba_hist_undostat ， dba_hist_waitstat ....里面有很多视图值得我们去看看，对于理解awr机制很有用

以select * from dba_hist_waitstat;举例

我们再查数据库等待事件：
select * from v$waitstat;

从上面发现snap_id为439里的数据都是从v$waitstat视图里取样的。
下面我们生成一个awr报告：（也可以用em生成报告）
SQL> @ /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/awrrpt.sql


Current Instance
~~~~~~~~~~~~~~~~


   DB Id    DB Name      Inst Num Instance
----------- ------------ -------- ------------
 3848072073 ORCL3939            1 orcl3939




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'
输入 report_type 的值:  
................
................
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.


输入 num_days 的值:  5


Listing the last 5 days of Completed Snapshots


                                                        Snap
Instance     DB Name        Snap Id    Snap Started    Level
------------ ------------ --------- ------------------ -----
orcl3939     ORCL3939           450 20 4月  2015 00:00     1


                                451 20 4月  2015 12:36     1
                                452 20 4月  2015 14:00     1
                                453 20 4月  2015 15:01     1
                                454 20 4月  2015 16:00     1
                                455 20 4月  2015 17:00     1
                                456 20 4月  2015 18:00     1
                                457 20 4月  2015 19:00     1


                                458 21 4月  2015 12:11     1
                                459 21 4月  2015 13:00     1
                                460 21 4月  2015 14:00     1
                                461 21 4月  2015 15:00     1
                                462 21 4月  2015 16:01     1
                                463 21 4月  2015 17:00     1
                                464 21 4月  2015 18:00     1
                                465 21 4月  2015 19:00     1


                                466 22 4月  2015 12:43     1
                                467 22 4月  2015 14:01     1
                                468 22 4月  2015 15:00     1
                                469 22 4月  2015 16:00     1
                                470 22 4月  2015 17:00     1
                                471 22 4月  2015 18:01     1
                                472 22 4月  2015 19:01     1
                                473 22 4月  2015 20:00     1
                                474 22 4月  2015 21:00     1
                                475 22 4月  2015 22:03     1
                                476 22 4月  2015 23:00     1


                                477 23 4月  2015 11:13     1
                                478 23 4月  2015 12:00     1
                                479 23 4月  2015 13:00     1
                                480 23 4月  2015 14:00     1
                                481 23 4月  2015 15:00     1
                                482 23 4月  2015 16:00     1
                                483 23 4月  2015 17:00     1
                                484 23 4月  2015 18:00     1
                                485 23 4月  2015 19:00     1
                                486 23 4月  2015 20:00     1
                                487 23 4月  2015 21:00     1
                                488 23 4月  2015 22:00     1
                                489 23 4月  2015 23:00     1


                                490 24 4月  2015 12:32     1






Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
输入 begin_snap 的值:  

....................
...................
截自部分：

WORKLOAD REPOSITORY report for


DB Name         DB Id    Instance     Inst Num Startup Time    Release     RAC
------------ ----------- ------------ -------- --------------- ----------- ---
ORCL3939      3848072073 orcl3939            1 23-4月 -15 11:03 11.2.0.1.0  NO


Host Name        Platform                         CPUs Cores Sockets Memory(GB)
---------------- -------------------------------- ---- ----- ------- ----------
localhost.locald Linux IA (32-bit)                   2                      .99


              Snap Id      Snap Time      Sessions Curs/Sess
            --------- ------------------- -------- ---------
Begin Snap:       488 23-4月 -15 22:00:53       42       4.5
  End Snap:       489 23-4月 -15 23:00:07       36       4.9
   Elapsed:               59.24 (mins)
   DB Time:                9.48 (mins)


Cache Sizes                       Begin        End
~~~~~~~~~~~                  ---------- ----------
               Buffer Cache:        72M        72M  Std Block Size:         8K
           Shared Pool Size:       152M       152M      Log Buffer:     5,952K


Load Profile              Per Second    Per Transaction   Per Exec   Per Call
~~~~~~~~~~~~         ---------------    --------------- ---------- ----------
      DB Time(s):                0.2                0.6       0.00       0.07
       DB CPU(s):                0.1                0.2       0.00       0.02
       Redo size:           18,596.5           68,566.9
   Logical reads:              354.8            1,308.3
   Block changes:              132.5              488.6
  Physical reads:                7.9               29.2
 Physical writes:                2.8               10.3
      User calls:                2.4                9.0
          Parses:                9.7               35.7
     Hard parses:                0.8                2.9
W/A MB processed:                0.1                0.2
          Logons:                0.1                0.3
        Executes:               34.6              127.5
       Rollbacks:                0.0                0.0
    Transactions:                0.3


Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:  100.00       Redo NoWait %:  100.00
            Buffer  Hit   %:   97.77    In-memory Sort %:  100.00
            Library Hit   %:   94.34        Soft Parse %:   91.99
         Execute to Parse %:   72.02         Latch Hit %:   99.99
Parse CPU to Parse Elapsd %:   46.20     % Non-Parse CPU:   91.64


 Shared Pool Statistics        Begin    End
                              ------  ------
             Memory Usage %:   77.23   82.51
    % SQL with executions>1:   75.48   77.77
  % Memory for SQL w/exec>1:   69.86   78.52


Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU                                              175          30.7
db file sequential read               9,109         117     13   20.6 User I/O
db file scattered read                1,324          29     22    5.0 User I/O
virtual circuit wait                    272          22     83    4.0 Network
log file sync                           291          10     34    1.8 Commit
Host CPU (CPUs:    2 Cores:  Sockets: )
~~~~~~~~         Load Average
               Begin       End     %User   %System      %WIO     %Idle
           --------- --------- --------- --------- --------- ---------
                0.62      0.13       2.6       0.7       3.5      96.3


Instance CPU
~~~~~~~~~~~~
              % of total CPU for Instance:       3.1
              % of busy  CPU for Instance:      84.3
  %DB time waiting for CPU - Resource Mgr:       0.0


Memory Statistics
~~~~~~~~~~~~~~~~~                       Begin          End
                  Host Mem (MB):      1,010.8      1,010.8
                   SGA use (MB):        264.0        264.0
                   PGA use (MB):        116.6         79.2
    % Host Mem used for SGA+PGA:        37.66        33.95


.............
.............
db time:所有活动session的总时间
正常情况下，db time 和cpu time时间大致相等，但是如果是性能问题，往往db time 是 cpu time很多倍。
AWR信息量很大,不但统计了数据库的几乎所有的历史信息而且包括系统信息。

ADDM:auto database diagnostic monitor(数据库自动诊断监控）
发现数据库性能问题时，可以创建addm报告，数据库给你建议信息（也可以在em上生成）
下面创建一个addm报告：需要输入snap_id
SQL> @ /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/addmrpt.sql


Current Instance
~~~~~~~~~~~~~~~~
DB Id    DB Name      Inst Num Instance
----------- ------------ -------- ------------
 3848072073 ORCL3939            1 orcl3939

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

  DB Id     Inst Num DB Name      Instance     Host
------------ -------- ------------ ------------ ------------
* 3848072073        1 ORCL3939     orcl3939     localhost.lo
                                                caldomain
  3848072073        1 ORCL3939     orcl3939     cmwap.cqmc.c
                                                om
Using 3848072073 for database Id
Using          1 for instance number

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.

Listing the last 3 days of Completed Snapshots


                                                        Snap
Instance     DB Name        Snap Id    Snap Started    Level
------------ ------------ --------- ------------------ -----
orcl3939     ORCL3939           466 22 4月  2015 12:43     1
                                467 22 4月  2015 14:01     1
                                468 22 4月  2015 15:00     1
                                469 22 4月  2015 16:00     1
                                470 22 4月  2015 17:00     1
                                471 22 4月  2015 18:01     1
                                472 22 4月  2015 19:01     1
                                473 22 4月  2015 20:00     1
                                474 22 4月  2015 21:00     1
                                475 22 4月  2015 22:03     1
                                476 22 4月  2015 23:00     1


                                477 23 4月  2015 11:13     1
                                478 23 4月  2015 12:00     1
                                479 23 4月  2015 13:00     1
                                480 23 4月  2015 14:00     1
                                481 23 4月  2015 15:00     1
                                482 23 4月  2015 16:00     1
                                483 23 4月  2015 17:00     1
                                484 23 4月  2015 18:00     1
                                485 23 4月  2015 19:00     1
                                486 23 4月  2015 20:00     1
                                487 23 4月  2015 21:00     1
                                488 23 4月  2015 22:00     1
                                489 23 4月  2015 23:00     1


                                490 24 4月  2015 12:32     1

Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
输入 begin_snap 的值:  
...................
..................
下面截取信息：
       任务 '任务_1273' 的 ADDM 报告
          ----------------------
分析时段
----
AWR 快照范围从 488 到 489。
时段从 23-4月 -15 10.00.54 下午 开始
时段在 23-4月 -15 11.00.08 下午 结束


分析目标
----
数据库 'ORCL3939' (DB ID 为 3848072073)。
数据库版本 11.2.0.1.0。
ADDM 对实例 orcl3939 执行了分析, 该实例的编号为 1 并运行于 localhost.lo
caldomain。
分析时段期间的活动
---------
总数据库时间为 569 秒。
活动会话的平均数量为 .16。


查找结果概要
------
   说明               活动的会话   建议案
                    活动的百分比
   ---------------  ------  ---
1  "用户 I/O" 等待类     .04 | 25.640
2  硬语法分析            .03 | 19.860
3  I/O 吞吐量          .01 | 7.972
4  特殊的 "网络" 等待事件    .01 | 3.951
5  PL/SQL 编译        0 | 2.541
6  由于共享标准而产生的硬语法分析  0 | 2.521
7  软语法分析            0 | 2.252
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  查找结果和建议案
          --------
查找结果 1: "用户 I/O" 等待类
受影响的是 .04 个活动会话, 占总活动的 25.64\%。
-------------------------------
等待类 "用户 I/O" 消耗了大量数据库时间。
Oracle 实例内存 (SGA 和 PGA) 大小合适。
没有可用的建议案。
查找结果 2: 硬语法分析
受影响的是 .03 个活动会话, 占总活动的 19.86\%。
-------------------------------
对 SQL 语句的硬语法分析消耗了大量数据库时间。
出现语法分析错误的 SQL 语句的硬语法分析并未消耗大量数据库时间。
由于使用了文字和游标失效而产生的硬语法分析并未消耗大量数据库时间。
Oracle 实例内存 (SGA 和 PGA) 大小合适。
没有可用的建议案。
查找结果 3: I/O 吞吐量
受影响的是 .01 个活动会话, 占总活动的 7.97\%。
------------------------------
I/O 子系统的吞吐量比预期吞吐量小得多。
建议案 1: 主机配置
   估计的收益为 .01 个活动会话, 占总活动的 7.97\%。
   -------------------------------
   操作
      考虑增加 I/O 子系统的吞吐量。Oracle 建议的解决方案是使用 SAME
      方法将所有数据文件条带化。您可能还需要增加磁盘数量以获得更好的性能。
   原理
      分析期间, 数据文件的平均 I/O 吞吐量, 对于读取为每秒 62 K, 对于写入为每秒 2
1 K。单个块读取的平均响应时间为 14 毫秒。
 建议案 2: 主机配置
   估计的收益为 .01 个活动会话, 占总活动的 6.93\%。
   -------------------------------
   操作
      某些数据和临时文件的性能比其他数据和临时文件低得多。如果不能使用 SAME 方法
将所有的文件条带化, 可考虑将这些文件条带化至多个磁盘。    原理
      对于文件 /u01/app/oracle/oradata/orcl3939/sysaux01.dbf, 单个块读取的平均响
应时间为 27 毫秒,
      额外 I/O 等待总时间为 23 秒。
      相关对象
         数据库文件
         "/u01/app/oracle/oradata/orcl3939/sysaux01.dbf"
   原理
      对于文件 /u01/app/oracle/oradata/orcl3939/system01.dbf, 单个块读取的平
均响应时间为 13 毫秒,
      额外 I/O 等待总时间为 15 秒。
      相关对象
         数据库文件
         "/u01/app/oracle/oradata/orcl3939/system01.dbf"
 导致查找结果的故障现象:
   ------------
      等待类 "用户 I/O" 消耗了大量数据库时间。
      受影响的是 .04 个活动会话, 占总活动的 25.64\%。
查找结果 4: 特殊的 "网络" 等待事件
受影响的是 .01 个活动会话, 占总活动的 3.95\%。
------------------------------
等待事件 "virtual circuit wait" (在等待类 "Network" 中) 消耗了大量数据库时间。


   建议案 1: 应用程序分析
   估计的收益为 .01 个活动会话, 占总活动的 3.95\%。
   -------------------------------
   操作
      研究 "virtual circuit wait" 等待数较大的原因。有关此等待事件的说明, 请参阅
 Oracle 的 "Database
      Reference"。
 导致查找结果的故障现象:

   建议案 1: 应用程序分析
   估计的收益为 0 个活动会话, 占总活动的 2.52\%。
   -----------------------------
   操作
      查找 V$SQL_SHARED_CURSOR 中游标环境不匹配的最主要原因。
 附加信息
          ----
各种信息
----
等待类 "应用程序" 并未消耗大量数据库时间。
等待类 "提交" 并未消耗大量数据库时间。
等待类 "并发" 并未消耗大量数据库时间。
等待类 "配置" 并未消耗大量数据库时间。
CPU 不是此实例的瓶颈。
会话连接和断开连接的调用并未消耗大量数据库时间。
在分析时段的 100% 期间, 数据库的维护窗口是处于活动状态的。