oracle awr与ash性能报告深入解析,Oracle AWR 与 ASH 性能报告深入解析

《Oracle  AWR 与 ASH 性能报告深入解析》

一  数据库版本

LEO1@LEO1> select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

PL/SQL Release 11.2.0.1.0 - Production

CORE    11.2.0.1.0      Production

TNS for Linux: Version 11.2.0.1.0 - Production

NLSRTL Version 11.2.0.1.0 - Production

二  AWR 性能诊断报告

AWR：Automatic Workload Repository 自动工作负载信息库

通常在诊断数据库性能的时候分三个阶段

第一阶段：SQL 语句级性能优化

第二阶段：session 级性能优化，这时我们可以用 ASH 来做分析

第三阶段：DB 级性能优化，AWR 就是数据库层性能诊断报告，当我们无法判断数据库哪里性能出现

问题时我们可以做一个全身体检报告来找到我们瓶颈所在。

AWR 机制：通过对系统整体动态采样收集快照信息，存储在 SYSAUX 表空间，每小时采样一次，可以

保存 7 天，MMON 进程实施，快照分析后写入 DBA_HIST_%开头的数据字典。

AWR 信息来源：DBA_HIST_%开头的数据字典，请见下图

LEO1@LEO1> select table_name from dictionary where table_name like 'DBA_HIST_%';

TABLE_NAME

------------------------------------------------

DBA_HIST_ACTIVE_SESS_HISTORY

DBA_HIST_ASH_SNAPSHOT

DBA_HIST_BASELINE

DBA_HIST_BASELINE_DETAILS

DBA_HIST_BASELINE_METADATA

DBA_HIST_BASELINE_TEMPLATE

DBA_HIST_BG_EVENT_SUMMARY

DBA_HIST_BUFFERED_QUEUES

DBA_HIST_BUFFERED_SUBSCRIBERS

DBA_HIST_BUFFER_POOL_STAT

DBA_HIST_CLUSTER_INTERCON

DBA_HIST_COLORED_SQL

DBA_HIST_COMP_IOSTAT

DBA_HIST_CR_BLOCK_SERVER

DBA_HIST_CURRENT_BLOCK_SERVER

DBA_HIST_DATABASE_INSTANCE

DBA_HIST_DATAFILE

DBA_HIST_DB_CACHE_ADVICE

…………………………………………………

109 rows selected.

AWR 信息就是来自上面这些数据字典表， 它是把这些表中数据进行汇总统计后生成 HTML or TXT 格式

LEO1@LEO1> select snap_id,name,value from DBA_HIST_SGA where snap_id>=173 and snap_id<=174;

SNAP_ID NAME                                                                  VALUE

---------- ----------------------------------------------------------------------------------------------------------------------------------

173 Database Buffers                                                  117440512

173 Fixed Size                                                          2214856

173 Redo Buffers                                                        8052736

173 Variable Size                                                     385877048

174 Database Buffers                                                  117440512

174 Fixed Size                                                          2214856

174 Redo Buffers                                                        8052736

174 Variable Size                                                     385877048

上面这个例子显示了 173-174 快照中 SGA 的信息

OEM 可以生成图形化性能分析图，UI 版 AWR

AWR 基线：我们可以在数据库平稳正常的状态下创建 AWR 基线(参照物) ，在实际生产中可以作为

性能指标曲线的一个参照物， 有了基线对比， 我们就可以很方便的了解到系统的一个真实的性能趋势。

AWR 创建：sqlplus / as system @下面的脚本就可以创建 AWR 报告了

创建脚本目录：/u01/app/oracle/product/11.2.0/db_1/rdbms/admin/awrrpt.sql

AWR 报告分析说明

1. WORKLOAD REPOSITORY report for

2.

DB Name

DB Id

Instance

Inst num

Startup Time

Release

RAC

EMSTA

433507400 emsta1

1 14-Aug-12 22:08

11.2.0.2.0

YES

Host Name

Platform

CPUs

Cores

Sockets

Memory (GB)

emsta1

Solaris[tm] OE (64-bit)

64

32

8

128.00

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

6023

07-Sep-12 14:00:09

1788

2.8

End Snap:

6026

07-Sep-12 17:00:06

1793

2.9

Elapsed:

179.94 (mins)

DB Time:

79.25 (mins)

数据库名：EMSTA   DB ID：433507400  实例名：emsta1  第一个实例   启动时间   版本  是 RAC

主机名：emsta1  操作系统平台：Solaris 64 位  64 颗 CPU  32 核  内存：128GB

由上述硬件判断这是 2 台小机组成的 RAC 模式数据库，上面的是实例 1，下面的是实例 2，名称后缀

不同。

起始快照 id：6023

终止快照 id：6026   快照与快照间隔 1 小时从 14：00~17：00 一共 3 小时采样信息

起始快照与终止快照间隔时间：180 分钟

所有用户使用数据库时间总和(累加值) ：80 分钟

起始时间有 1788 个会话，每个会话使用 2.8 个游标

结束时间有 1793 个会话，每个会话使用 2.9 个游标

DB Name

DB Id

Instance

Inst num

Startup Time

Release

RAC

EMSTA

433507400 emsta2

2 14-Aug-12 22:08

11.2.0.2.0

YES

Host Name

Platform

CPUs

Cores

Sockets

Memory (GB)

emsta2

Solaris[tm] OE (64-bit)

64

32

8

128.00

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

6023

07-Sep-12 14:00:09

1363

3.0

End Snap:

6026

07-Sep-12 17:00:06

1378

3.0

Elapsed:

179.94 (mins)

DB Time:

136.61 (mins)

实例 2 中各个部分的含义值和实例 1 相同，这里不再另外说明

2.cache size

Begin

End

Buffer Cache:

15,360M

15,360M Std Block Size:

8K

Shared Pool Size:

6,272M

6,272M Log Buffer:

111,456K

Instance1：数据库缓冲区 15360M

共享池 6272M

redo log 缓冲区 111.456M

数据块大小 8K

Buffer Cache:

13,696M

13,696M Std Block Size:

8K

Shared Pool Size:

6,144M

6,144M Log Buffer:

111,456K

Instance2：数据库缓冲区 13696M

共享池 6144M

redo log 缓冲区 111.456M

数据块大小 8K

2 个实例的 SGA 有一点点的大小差异，但是差距不大。

3.Load profile

数据库负载属性信息  美秒      每个事物       每次执行  每次调用

Per Second

Per Transaction

Per Exec

Per Call

DB Time(s):

0.4

0.3

0.01

0.00

DB CPU(s):

0.4

0.2

0.01

0.00

Redo size:

15,275.9

8,983.0

Logical reads:

13,716.1

8,065.8

Block changes:

79.2

46.6

Physical reads:

365.3

214.8

Physical writes:

4.5

2.7

User calls:

232.7

136.8

Parses:

11.4

6.7

Hard parses:

0.3

0.2

W/A MB processed:

2.7

1.6

Logons:

0.0

0.0

Executes:

54.3

32.0

Rollbacks:

0.0

0.0

Transactions:

1.7

Instance1：逻辑读和物理读较多，是以读为主

Instance2：物理写较多，是以写为主

如果我们有一个基线值，就好比较性能优略了

Per Second

Per Transaction

Per Exec

Per Call

DB Time(s):

0.8

0.1

0.00

0.00

DB CPU(s):

0.4

0.1

0.00

0.00

Redo size:

102,788.5

11,594.5

Logical reads:

4,287.6

483.6

Block changes:

436.4

49.2

Physical reads:

100.5

11.3

Physical writes:

40.6

4.6

User calls:

261.7

29.5

Parses:

108.9

12.3

Hard parses:

0.1

0.0

W/A MB processed:

0.9

0.1

Logons:

3.1

0.4

Executes:

263.1

29.7

Rollbacks:

0.0

0.0

Transactions:

8.9

业务类型不同关注数据指标也不同

OLAP：关注 IO 指标

OLTP：关注内存 CPU 指标

4.Top 5 Timed Foreground Events

Instance1：这是排名前五位的前台等待事件(用户 SQL 的等待事件)

DB CPU：数据库消耗 CPU 时间(所有用户使用 CPU 的累加值)

Waits：等待了多少次

Times：等待了多少秒

Avg wait(ms) ：平均等待一次多少毫秒

%DB time：占整体数据库时间的百分比，我们看到 CPU 消耗占了 82%，应该解析的 SQL 语句比较多

Wait Class：等待类型

Instance2：%DB time 54% 也是排名第一，说明解析和执行的 SQL 语句很多

5.CPU&MEMORY 统计信息

Instance1

CPU %Idle：空闲率 98% 看来 CPU 的使用率不高啊

%Busy CPU：忙时 CPU 占用 53.9%

而且 CPU 等待时间占整体等待时间比例很小

SGA+PGA 使用率占物理内存的 19%，内存空闲空间还很高，我们还可以增加 SGA+PGA 容量缓存更多

的 SQL

Instance2 与 Instance1 还是很相近的

6.RAC 性能报告

AWR 信息太多，这里简要截图举例说明

实例数从快照开始到快照结束都是 2

Instance1 每秒全局缓冲区接收块数 6 个

每个事物接收块数 3 个

DBRW Fusion write 0.2 写的不是很多，大部分动作都在读

Instance2 每秒全局缓冲区接收块数 21 个，这个要比 Instance1 的多

每个事物接收块数 2 个，比 Instance1 的少

7.按照消耗时间排名

Instance1：SQL 执行处理时间，消耗时间最多

CPU 使用时间排第二

从这 2 点可以推断出，这是一个 OLTP 系统，主要消耗资源在 CPU 上而不是 IO 上

Instance2：CPU 使用时间最多

8.Foreground Wait Class 前台进程等待事件(用户触发的)

Instance1

按等待类型分类：还是 CPU 消耗的时间最多

Instance2：Network 资源等待时间较长，说明数据块在 2 个实例间交叉复制和传输较多

9.Background Wait Events 后台进程等待事件(数据库后台进程触发的)

这里列举了数据库后台进程的等待事件排名，我们可以看这些来判断哪些资源使用的较多

10.Instance Activity Stat  实例活跃度

IO 向量统计排名最多

小结：我们从上面的各种指标参数来分析 CPU 资源消耗的较多，IO 资源相对较少，根据不同业务类

型关注指标类型不同判断这个 RAC 系统是一个 OLTP 系统。

(1).我们首先要了解系统的业务种类 AWR 报告才能定位准确。

(2).OLTP 多关注 CPU&MEMORY 指标(软硬解析  cursor 共享  绑定变量  SGA 命中率)

OLAP 多关注 IO 指标(物理/逻辑读写  一致性  数据块大小  数据块吞吐量  追踪 SQL 进行优化)

(3).面->线->点：AWR -> TOP 5 -> 哪块资源有问题

三 产生一个 ASH 报告，并进行分析，给出最后的结论。

ASH：Active Session History 活动会话历史记录

ASH 是一个会话级别的性能诊断报告，可以提供更细粒度的时间区间，可以精确到分钟，ASH 可以提

供比 AWR 更详细的关于历史会话的信息，可以作为 AWR 的补充。

ASH 信息来源“v$active_session_history”   保存当前会话的采集信息(一秒钟一次快照) ，视图容量

满后可以被覆盖，可以从下面的数据字典中寻找

“dba_hist_active_sess_history”保持历史会话的采集信息

生成 ASH 报告

创建脚本目录：/u01/app/oracle/product/11.2.0/db_1/rdbms/admin/ashrpt.sql

ASH 创建：sqlplus leo1/leo1 @创建脚本

[oracle@leonarding1 ~]$ sqlplus leo1/leo1

@/u01/app/oracle/product/11.2.0/db_1/rdbms/admin/ashrpt.sql

Current Instance

~~~~~~~~~~~~~~~~

DB Id    DB Name      Inst Num Instance

----------- ------------ -------- ------------

1678393804 LEO1                1 LEO1

数据库 id    数据库名    实例数量    实例名

Specify the Report Type

~~~~~~~~~~~~~~~~~~~~~~~

Enter 'html' for an HTML report, or 'text' for plain text     指定生成 ASH 报告类型 HTML or TXT

Defaults to 'html'                                   默认是 HTML

Enter value for report_type:                          我们直接回车生成 HTML 类型

Specify the timeframe to generate the ASH report         指定 ASH 报告采集时间区间

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enter begin time for report:

--    Valid input formats:

--      To specify absolute begin time:

--        [MM/DD[/YY]] HH24:MI[:SS]

--        Examples: 02/23/03 14:30:15                  样例

--                  02/23 14:30:15

--                  14:30:15

--                  14:30

--      To specify relative begin time: (start with '-' sign)

--        -[HH24:]MI

--        Examples: -1:15  (SYSDATE - 1 Hr 15 Mins)      可以当前时间减去指定的分钟数

--                  -25    (SYSDATE - 25 Mins)

Defaults to -15 mins                                  默认减去 15 分钟

Enter value for begin_time: 03/11/13 00:00:00             我指定开始时间是 2013 年 3 月 11 日零点

Report begin time specified: 03/11/13 00:00:00

Enter duration in minutes starting from begin time:

Defaults to SYSDATE - begin_time                       默认是当前时间-03/11/13 00:00:00

Press Enter to analyze till current time

Enter value for duration:                              现在是 03/11/13 00:35:00，我们按回车

Specify the Report Name                             指定 ASH 报告名称，可以加创建到哪的路径

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is ashrpt_1_0311_0035.html.  To use this name, 默认名称

press to continue, otherwise enter an alternative.

Enter value for report_name: /home/oracle/ashrpt_leo1_0000_0035.html

Report written to /home/oracle/ashrpt_leo1_0000_0035.html   报告已经创建到指定目录

LEO1@LEO1>

我们打开 ASH 报告 ashrpt_leo1_0000_0035.html

1.数据库概括信息

数据库名：LEO1

数据库 id：1678393804

实例名：LEO1

实例数：1

版本：11.2.0.1.0

RAC：NO

主机名：leonarding1.oracle.com

CPUs：2 核

SGA Size：490M   其中 data_buffer_cache 112M  shared pool 184M ASH buffer size 4M

ASH 采样开始时间：2013-03-11 00:00:00     ASH 信息来源“v$active_session_history”

ASH 采样结束时间：2013-03-11 00:35:00

间隔时间：36 分钟

采样数：416

平均活动会话：0.19

每个 CPU 执行平均会话数：0.10

这么一看跟 AWR 上来阐述系统概括信息差不多

2.Top User Events  前 5 名等待事件

事件名 事件类型 占整体百分比 平均会话数

CPU 等待时间最长 CPU  37.26  0.07

这是我自己的实验环境，没有很多并发会话，所以活动会话数比较少

这是等待事件的详细信息

3.Top SQL 性能最差 SQL 排名

按等待事件排名 SQL

按数据处理方式排名 SQL

4.Top Sessions  按会话信息排名

一个会话由：sid+serial#来唯一定位的

5.Top Objects & Files  按数据库对象和数据文件排名

看第二行就是我们经常使用的 LEO5 表，object_id=74268

因为我们刚刚做了 AWR 和 ASH 报告，用 sysaux 表空间较多，因此排第一位

小结：ASH 主要是针对会话级的一个体检报告，它可以追踪历史会话，从会话的角度分析数据库性能

瓶颈，从而找到 SQL，优化 SQL 语句。

四 分析说明 ASH 和 AWR 报告的使用场景

AWR：如果想全面了解数据库各个方面性能的话(包括 硬件 软件 应用 数据库)可以使用 AWR 报

告，实例级别诊断报告

ASH：如果想了解关于历史会话的信息可以使用 ASH 报告，会话级别诊断报告

场景功能对比

AWR   VS   ASH

Instance wide data 实例级广泛数据               Yes          Yes

Time based data 基于时间统计数据               Yes          Yes

Counts/occurrence data 计数/统计数据            No          Yes

Analyze any time period 在任何时间段做分析       Yes          No

Detailed session level data 会话级详细数据         Yes          No

Individual Wait event data 个别等待事件           Yes          No

Sampled data           采集样本数据           Yes          No

Time based analysis      基于时间分析           Yes          Yes

AWR  ASH  session  OLTP  OLAP  Repository

Leonarding

2013.3.10

天津&spring

分享技术~成就梦想

Blog：

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29477231/viewspace-1151693/，如需转载，请注明出处，否则将追究法律责任。