转载了两份只为平时查看方便。。在此谢谢原作者

一：

第一次看到awr报告，里面包含很多东西，完全不知道从哪里看起也不知道各项指标都是什么含义，从头到尾看了一遍，啥也没有看到，看了后面忘了前面的，花费一天的时间去熟悉它，在网上查资料对着报告一项项的熟悉了一遍

DB Name	DB Id	Instance	Inst num	Startup Time	Release	RAC
Db10	663168021	Db10	1	28-5月 -12 22:05	11.2.0.1.0	NO

Host Name	Platform	CPUs	Cores	Sockets	Memory (GB)
PC-200910080511	Microsoft Windows IA (32-bit)	2	2	1	.75

	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	73	28-5月 -12 22:28:57	23	1.5
End Snap:	74	28-5月 -12 23:00:43	23	1.5
Elapsed:		31.76 (mins)
DB Time:		0.10 (mins)

DB Name ：数据库名字 DBid: 数据库id

DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间，说明数据库比较空闲。在31分钟里，数据库耗时0.1分钟，数据中显示系统有2个CPU

Load Profile

	Per Second	Per Transaction	Per Exec	Per Call
DB Time(s):	0.0	0.0	0.00	0.02
DB CPU(s):	0.0	0.0	0.00	0.02
Redo size:	5,896.4	59,450.5
Logical reads:	71.9	724.7
Block changes:	41.1	414.7
Physical reads:	2.2	21.9
Physical writes:	0.9	9.2
User calls:	0.2	1.8
Parses:	3.7	37.6
Hard parses:	0.3	2.5
W/A MB processed:	0.0	0.2
Logons:	0.1	0.6
Executes:	8.1	81.7
Rollbacks:	0.0	0.0
Transactions:	0.1

Load Profile

Per Second Per Transaction

这两部分是数据库资源负载的一个明细列表，分割成每秒钟的资源负载和每个事务的资源负载情况，性能指标的含义如下：

redo size: 每秒/每个事务产生的redo量 (单位字节)

logical reads: 每秒/每个事务产生的逻辑读的块数

block changes: 每秒/每个事务改变的数据块数

physical reads: 每秒/每个事务产生的物理读

physical writes: 每秒/每个事务产生的物理写的块数

user calls: 每秒/每个事务用户的调用次数

parses: 每秒/每个事务分析次数

hard parses: 每秒/每个事务硬分析次数

sorts: 每秒/每个事务排序次数

logons: 每秒/每个事务登录数据库次数

executes: 每秒/每个事务 SQL的执行次数

rollbacks: 每秒/每个事物回滚次数

transactions: 每秒的事务数

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:	100.00	Redo NoWait %:	100.00
Buffer Hit %:	96.98	In-memory Sort %:	100.00
Library Hit %:	90.91	Soft Parse %:	93.27
Execute to Parse %:	53.96	Latch Hit %:	99.99
Parse CPU to Parse Elapsd %:	64.26	% Non-Parse CPU:	67.81

Buffer Nowait：表示在内存获得数据的未等待比例。

buffer hit：表示进程从内存中找到数据块的比率，内存数据块命中率

Redo NoWait：表示在LOG缓冲区获得BUFFER的未等待比例。

library hit：表示共享池中SQL解析的命中率

Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。

Parse CPU to ParseElapsd：解析总时间中消耗总CPU的时间百分比

Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。

Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。

In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。

Soft Parse：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。

Shared Pool Statistics

	Begin	End
Memory Usage %:	84.18	83.00
% SQL with executions>1:	74.54	76.34
% Memory for SQL w/exec>1:	78.06	73.38

Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。

SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。

Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。

Top 5 Timed Foreground Events

Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
DB CPU		5		87.64
db file sequential read	258	1	5	22.30	User I/O
library cache load lock	1	0	87	1.45	Concurrency
db file scattered read	17	0	3	0.85	User I/O
log file sync	35	0	1	0.77	Commit

这是报告概要的最后一节，显示了系统中最严重的5个等待，按所占等待时间的比例倒序列示。当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。

通常，在没有问题的数据库中，CPUtime总是列在第一个

SQL Statistics

SQL ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by User I/O Wait Time
SQL ordered by Gets
SQL ordered by Reads
SQL ordered by Physical Reads (UnOptimized)
SQL ordered by Executions
SQL ordered by Parse Calls
SQL ordered by Sharable Memory
SQL ordered by Version Count
Complete List of SQL Text

二、解析报告

1.SQL ordered by Elapsed Time：

记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间 Elapsed Time = CPU Time + Wait Time)

Elapsed Time(S): SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒。Elapsed Time = CPU Time + Wait Time

CPU Time(s): 为SQL语句执行时CPU占用时间总时长，此时间会小于等于Elapsed Time时间。单位时间为秒。

Executions: SQL语句在监控范围内的执行次数总计。

Elap per Exec(s): 执行一次SQL的平均时间。单位时间为秒。

% Total DB Time: 为SQL的Elapsed Time时间占数据库总时间的百分比。

SQL ID: SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQL ID的地方。

SQL Module: 显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。

SQL Text: 简单的sql提示，详细的需要点击SQL ID。

2. SQL ordered by CPU Time:

记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。

3. SQL ordered by Gets:

记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets).

4. SQL ordered by Reads:

记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)。

5. SQL ordered by Executions:

记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。

6. SQL ordered by Parse Calls:

记录了SQL的软解析次数的TOP SQL。

7. SQL ordered by Sharable Memory:

记录了SQL占用library cache的大小的TOP SQL。

Sharable Mem (b)：占用library cache的大小。单位是byte。

8. SQL ordered by Version Count:

记录了SQL的打开子游标的TOP SQL。

二：

1、AWR报告头信息

· DB Name ：数据库名字 DBid: 数据库id

· Elapsed:采样时间段

· DB Time:用户操作花费的时间,不包括Oracle后台进程消耗的时间

· DB Time远小于Elapsed Time说明数据库比较空闲

2、AWR负载概要信息

· Per Second 和Per Transaction：这两部分是数据库资源负载的一个明细列表，分割成每秒钟的资源负载和每个事务的资源负载情况

· Redo size：每秒/每个事务产生的redo量 (单位字节) 标志数据库的繁忙程度

· logical reads：每秒/每个事务产生的逻辑读的块数

· block changes：每秒/每个事务改变的数据块数

· physical reads：每秒/每个事务产生的物理读

· physical writes：每秒/每个事务产生的物理写的块数

· user calls：每秒/每个事务用户的调用次数

· parses：每秒/每个事务分析次数小于300则表示正常

· hard parses: 每秒/每个事务硬分析次数小于100则表示正常

· sorts: 每秒/每个事务排序次数

· logons: 每秒/每个事务登录数据库次数

· executes: 每秒/每个事务 SQL的执行次数

· rollbacks: 每秒/每个事物回滚次数

· transactions: 每秒的事务数

3、AWR实例效率

· Buffer Nowait%：表示在内存获得数据的未等待比例

· Buffer Hit%：表示进程从内存中找到数据块的比率，内存数据块命中率。小于80%则要加大data buffer pool

· Library Hit%：表示共享池中SQL解析的命中率。若低于90%,则需要调大share pool

· Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。

· Parse CPU to Parse Elapsd：解析总时间中消耗总CPU的时间百分比

· Redo NoWait：表示在LOG缓冲区获得BUFFER的未等待比例。

· In-memory sort%：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。

· Soft Parse%：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。

· Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。

· Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。

4、共享池概要

· Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。

· SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。

· Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。

5、AWR TOP等待事件

显示了系统中最严重的5个等待，按所占等待时间的比例倒序列示。当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。

通常，在没有问题的数据库中，CPU time总是列在第一个。

6、AWR TOP SQL Tuning

17.png (77.52 KB, 下载次数: 0)

下载附件保存到相册

2014-12-21 11:19 上传

1）SQL ordered by Elapsed Time：记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间）

·       Elapsed Time(S): SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒
Elapsed Time = CPU Time + Wait Time

·       CPU Time(s): 为SQL语句执行时CPU占用时间总时长，此时间会小于等于Elapsed Time时间。单位时间为秒。

·       Executions: SQL语句在监控范围内的执行次数总计。

·       Elap per Exec(s): 执行一次SQL的平均时间。单位时间为秒。

·       % Total DB Time: 为SQL的Elapsed Time时间占数据库总时间的百分比。

·       SQL ID: SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQL ID的地方。

·       SQL Module: 显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。

·       SQL Text: 简单的sql提示，详细的需要点击SQL ID。

2）SQL ordered by CPU Time: 记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。

3）SQL ordered by Gets: 记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets).

4）SQL ordered by Reads: 记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)。

5）SQL ordered by Executions: 记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。

6）SQL ordered by Parse Calls: 记录了SQL的软解析次数的TOP SQL。

7）SQL ordered by Sharable Memory: 记录了SQL占用library cache的大小的TOP SQL。
   Sharable Mem (b)：占用library cache的大小。单位是byte。

8）SQL ordered by Version Count: 记录了SQL的打开子游标的TOP SQL。

   主要针对ordered by Elapsed time,orderedby CPUtime,orderedby gets,orderedby read排名前三SQL进行观察并调优.

Oracle对SQL处理的步骤：

1. 语法检查(检查SQL的拼写语法是否正确)

2. 语义检查(检查SQL中的访问对象是否存在及是否具备相应权限)

3. 进行解析(parse)(利用内部算法对SQL解析,生成解析树(parse tree)及执行计划(execution plan))à软硬解析发生在此过程中

4. 执行SQL，返回结果

ITPub博客

如何解读AWR

最新文章