ORACLE AWR报告生成步骤
（以PL/SQL中命令窗口为例）
1.sqlplus或plsql的commod窗口（命令窗口）运行命令 @D:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\awrrpt.sql;
然后在弹出的对话框中输入选择的导出格式html或者txt
2.在弹出的对话框中输入数字选择制定选择快照的数量
3.在接下来弹出的对话框中分别选择最小和最大snap_id
4.在弹出的对话框选择生成的ORACLE AWR（性能分析）报告的名称
5.在下图路径中可找到生成的ORACLE AWR报告（oracle性能分析报告）
6.双击即可查看报告内容
第二篇：解读ORACLE AWR报告
解读AWR报告
Basic Information
AWR报表的开头部分记录了数据库名称、DBID、实例名、实例号、上次启动时间、数据库版本、是否是RAC，以及机器名、操作系统类型、CPU个数、内存大小的信息。同时也会记录本AWR报表的snap id范围、snap时间范围，以及期间的session个数
Elapsed表示整个AWR报表统计的时间长度
DB Time是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间 DB Time= cpu time + wait time（不包含空闲等待） （非后台进程）
上述报表中
snapshot时间间隔为约111分钟，cpu就共有8*111=888分钟，DB time为265.10分钟，则： cpu花费了265.10分钟在处理Oracle非空闲等待和运算上(比如逻辑读),也就是说cpu有265.10/888*100%=29.8%花费在处理Oracle
的操作上，
这还不包括后台进程
从awr report的Elapsed time和DB Time就能大概了解db的负载，计算公式可参考为： cpu负载=DB Time/(cpu数*Elapsed)*100%
Cache Sizes
在后面一点，还有专门针对贡献内存使用情况的统计信息：
1.
2.
3. Memory Usage %：表示共享池内存使用率，应保持在75到90之间，太小说明分配的共享池过小，太大说明整个内存不足 % SQL with executions>1：执行次数大于1的SQL语句的比率，太小的话要结合Parse，看看是不是有硬编码现象 % Memory for SQL w/exec>1：执行次数大于1的SQL语句所消耗的内存，占所有SQL语
句消耗内存的比率。
Load Profile
Load Profile Per Second Per Transaction Per Exec Per Call ~~~~~~~~~~~~ --------------- --------------- ---------- ---------- DB Time(s): 2.4 0.0 0.00 0.00 DB CPU(s): 1.0 0.0 0.00 0.00 Redo size: 693,914.1 2,626.3
Logical reads: 191,810.0 726.0
Block changes: 3,777.2 14.3
Physical reads: 4,348.8 16.5
Physical writes: 67.6 0.3
User calls: 958.0 3.6
Parses: 280.2 1.1
Hard parses: 131.9 0.5
W/A MB processed: -12,448,398.5 -47,113.9
Logons: 0.1 0.0
Executes: 659.5 2.5
Rollbacks: 0.0 0.0
Transactions: 264.2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DB Time(s)：每秒内用于DB处理的时间，其他时间为等待时间
Redo size: 每秒产生的redo，单位为字节,其中Per Second表示每秒中产生的redo的字节数，Per Transaction表示每个事务产生的redo的字节数，
可以通过后者可以看到事务的大小，协助判断是否commit次数太多。例如per second很大，而per transaction很小，说明commit次数太多。
通常在很繁忙的系统中日志生成量可能达到上百k，甚至几百k。
Logical reads:每秒产生的逻辑读(我们可以这样认为，block在内存中，我们每一次读一块内存，就相当于一次逻辑读)，单位为块,在良好的OLTP环境中，
Logical reads/Executes不会超过50，一般只有10左右，如果该指标较大，表示语句可能不够优化，需要具体分析,在该示例中，191810/659=291，偏大
那么在OLAP中呢？
Block changes:每秒有多少个块发生变化
Physical reads:每秒数据库从磁盘读取的块个数
Physical writes:每秒有多少个块接受了数据库写入数据
User calls:每秒用户call次数，User calls/Executes基本代表每个语句的请求次数，Executes越接近User calls越好
Parses:每秒的SQL语句解析次数，超过300即需关注,可以考虑调整参数session_cursor_cache来改善解析次数过高的现象
Hard parses:硬解析次数,如果硬解析次数很高，例如超过100，基本都是由于不使用bind var所导致的,导致cpu使用率的问题，极有使得性能急剧下降
Executes:每秒/每事务产生的语句执行次数，包括用户执行的SQL语句与系统执行的SQL语句，表示一个系统SQL的繁忙程度。
Transactions:每秒产生的事务个数，反映数据库负载程度，不同的系统，略有差异，在典型的交易系统中，事务较多，而网站系统，可能select查询较多
Rollbacks: 表示数据库中事务的回退率。如果不是因为业务本身的原因，通常应该小于10%为好，回退是一个很消耗资源的操作。
Instance Efficiency Percentages Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.98 Redo NoWait %: 100.00
Buffer Hit %: 97.77 In-memory Sort %: 99.99
Library Hit %: 82.32 Soft Parse %: 52.94
Execute to Parse %: 57.51 Latch Hit %: 99.99
Parse CPU to Parse Elapsd %: 0.01 % Non-Parse CPU: 89.44
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %：
表示在数据缓冲区中获取buffer时，未进行等待的比率，越高越好；
Buffer Hit %：
数据块在数据缓冲区中的命中率，在典型的OLTP环境，命中率通常在95%以上，否则需要考虑加
大db_cache_size。
在数据仓库OLAP环境中，数据缓冲命中率不是一个重要的指标，因为OLAP数据库主要是物理读，
甚至是直接读，该命中率不可能高。
Library Hit %：
SQL语句在库缓冲中能否找到相应的解析计划，如果低于95，需考虑加大共享池，或检查是否有
硬编码现象
Execute to Parse %：
表示SQL语句解析后被重复执行命中率，计算公式=100*(1-Parses/Executions)，如果该值偏小，
说明分析(硬分析与软分析 )的比例较大，快速分析较少，
根据实际情况，可以考虑调整session_cached_cursors参数
有些报告中这个值是负的，看上去很奇怪。事实上这表示一个问题，sql如果被age out的话就可
能出现这种情况，也就是sql老化，
执行alter system flush shared_pool
Parse CPU to Parse Elapsd %：
表示解析实际耗用时间/(解析实际耗用时间＋等待资源的时间)，越高越好,在实际繁忙的系统
中，该值可能因为等待资源而不会太高
-----------------
Redo NoWait %：
在redo缓冲区中获取buffer的未等待比率
In-memory Sort %：
有多少排序是在内存中进行的。如果值偏低，说明有些排序是在temp表空间上进行的，性能肯定
不好，需调整PGA参数.sort_area_size
Soft Parse %：
SQL语句软解析占整个分析的命中率，如果低于95，需检查是否有硬编码现象，如果低于80，说
明SQL语句基本没有重用性
=soft/(soft+hard)
Latch Hit %：
表示内部结构维护锁命中率，通常高于99%，其值低是因为shared_pool_size过大或者没有使用
变量绑定导致硬解析过多。
% Non-Parse CPU：
SQL语句实际执行时间/( SQL语句实际执行时间+解析时间)，如果过低，说明解析时间所占比率
过高，考虑提高SQL语句重用性