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% 期间, 数据库的维护窗口是处于活动状态的。

时间： 2024-10-19 09:33:43

AWR ADDM的相关文章

Oracle性能调整ASH,AWR,ADDM

ASH (Active Session History)ASH以V$SESSION为基础,每秒采样一次,记录活动会话等待的事件.不活动的会话不会采样,采样工作由新引入的后台进程MMNL来完成.ASH buffers 的最小值为1MB,最大值不超过30MB.内存中记录数据.期望值是记录一小时的内容. 生成ASH报告:SQLPLUS>@?/rdbms/ashrpt.sql ASH内存记录数据始终是有限的,为了保存历史数据,引入了自动负载信息库(Automatic Workload Repositor

awr ash addm

awr addm :基于快照的ash :单独,每秒采样 dbtime=db cpu + wait 柜员忙碌的时间=A做业务的时间+B做业务的时间等待时间=B等待A做业务的时间 这是Oracle 核心的性能诊断模型. ash 写明了 哪个等待时间由那条sql引起 1 执行时间 2 最费cpu 3 逻辑读 4 read 物理读 5 最多执行 6 最占共享内存 7 解析调用最多 ash每秒采样 采样到sga 软肋:采样正确率,误差. v$active 1s dba_hist 10s V$ACTIVE_

（转载）Oracle AWR报告指标全解析

Oracle AWR报告指标全解析 2014-10-16 14:48:04 分类: Oracle [性能调优]Oracle AWR报告指标全解析 2013/08/31 BY MACLEAN LIU 26条评论 [性能调优]Oracle AWR报告指标全解析 开Oracle调优鹰眼,深入理解AWR性能报告:http://www.askmaclean.com/archives/awr-hawk-eyes-training.html 开Oracle调优鹰眼,深入理解AWR性能报告 第二讲: http:

Oracle AWR

oracle手工生成AWR报告方法记录 通过案例学调优之--AWR baseline对比生成AWR报告 Oracle性能调整的三把利剑--ASH,AWR,ADDM Oracle服务器系统负载过高的处理 oracle 查看系统历史运行负载脚本 如何捕获问题SQL解决过度CPU消耗问题 http://www.eygle.com/case/How.To.Capture.Problem.SQL.htm 如何诊断和解决CPU高度消耗(100%)的数据库问题 http://www.eygle.com/cas

Oracle快速收集AWR的方案

记一种方便的awr收集方法,该脚本可以按小时收集目标时段的awr 素材:awr_generate.sql (1)将awr_generate.sql置于数据库服务器本地路径F:\perf\awr下 (2)sqlplus连接数据库 C:\Users\Administrator>sqlplus / as sysdba (3)调用SQL脚本,时段参数等 SQL> @F:\perf\awr\awr_generate.sql Current Instance~~~~~~~~~~~~~~~~ DB Id D

实际工作规范和案例框架

菜刀: sql一刀剁了 整个模块丢弃了 调用次数少多了 排序不在需要了 大表砍成小表了 排重操作消失了 插入障碍小多了 迁移事情不做了 手术刀: 大表等于小表了 大表切成小表了 索引变身小表了 删除动作不做了 清表角度表换了 提交次数缩减了 迁移越来越快了 sql语句精简了 思路: 诊断 过程细化 找出细化项的主要矛盾 改进优化 理解需求 表明需求 隐藏需求 真正需求 设计 尽量不做事,甚至少做事. 选择相关工具,掌握相关技能 合理利用资源 规范: 数据库规范 学习规范 了解自己的职责 根据职责

Metric Manager

这部分和awr,ash,addm构成了oracle性能监控的一整套体系.内容涉及很多,下面不能够全面详细介绍,希望有抛砖引玉的作用. [[email protected] ~]$ lsb_release -a LSB Version:    :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: EnterpriseEnterpriseServer Description:    E

系统优化1--方法论

背景: 业务复杂 接口繁多 并发度高 访问量大 关注点: 性能指标 模块之间的关联 知识和方法论结合 性能问题的3种形态: 性能故障正在发生 故障发生了,又自动好了 故障还没有发生,但是在发生的路上 总体优化思路: 重要的前提: 了解业务的特点 掌握基线信息 确保有序调优: 先平台后应用 先整体后局部 先动态再静态 看时间消耗分布: 响应时间的整体分布状况 分析时间都消耗在哪些模块,应用,sql. 应用优化五步: 系统调研 业务背景 所在行业 使用人群 负载情况 在线用户数量 繁忙时段 技术架构

Oracle database 11g一些重要的初始化参数(一)

初始化参数文件位置 D:\app\Administrator\admin\orcl1\pfile\init.ora init.ora 1.diagnostic_dest 在11g中,有一种新的存储诊断信息的结构,称为自动诊断信息库(Automaticd Diagnostic Repository ADR). 用些参数指定目录位置,如$ORACLE_BASE/diag/rdbms/orcl/orcl.其中第一个orcl为数据库名,第二个orcl为实例名. 2. fixed_date 是11g中的一