《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：
一 数据库版本
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
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博客 ” ，链接：https://blog.itpub.net/29477231/viewspace-1151693/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
Oracle数据块损坏
下一篇：
没有了~
请登录后发表评论
登录
全部评论
