内容来自课堂整理、参考网络资料星球上最详细的AWR解析、Oracle AWR报告指标全解析
本文采用的命令和awr报告-使用的是Oracle 11G。
在正文开始前，首先你得知道AWR是什么，它可以解决什么问题，再判断你需不需要学习，如你需要，则进一步学如何使用AWR;反之，就不要浪费时间啦。
- awr 概念
awr 全称automatic Workload Pepository，帮助DBA迅速定位性能问题，oracle10G后出现，是Oracle运行过程中的信息收集工具。表现形式为：html/txt式的数据报告。
awr存放在sysaux表空间中，默认保留7天的快照，每隔1小时生成一次快照。(采样时间和保留天数是可修改的-请参考)
- 你使用现在/将来会使用到Oracle吗？-如不会，本文和你无关
- 你现在/将来-需要解决定位Oracle性能问题吗？-如不会，本文和你无关
awr报告生成和awr基线报告，请参考。
- awr使用策略
方法一(抓主要矛盾，解决主要问题)
拿到awr报告后，不建议从头看到尾，请先找问题，然后再根据问题-判断可能是因为什么引起的，然后去追踪、验证并定位问题。
一份awr报告在手，请先看“Top 5 Timed Foreground Events” ，该部分显示了系统中最严重的5个等待事件，请根据具体的等待事件去排查、分析问题。
Oracle的性能问题，最终都体现在SQL和配置上，SQL可单独拿出，通过执行计划来分析，进行优化；配置则可通过参考值/经验值，根据实际资源环境进行调高/调低。
方法二(对比分析法)
1)在系统运行正常时，使用awr生成一个基线报告。
- 当可能有问题时，再生成一个awr报告。
- 将当前报告和基线报告对比。
4)分析两份报告中不一样的地方，定位性能问题。
- awr报告详解和关联关系
awr报告由头部信息、摘要报告、主要报告三大块组成。
头部信息：确定oracle基本环境信息和报告数据范围。
摘要报告：是发现问题的起始点，它显示性能数据的统计信息，以便我们通过参考值/经验值去判断是否存在问题。
主要报告：是用来定位问题的，使用它能"摘要报告"中的问题和具体SQL一一对应上。
3.1 awr 报告头部信息
头部信息：确定oracle基本环境信息和报告数据范围
表格1用途：同一表象错误，会因版本和环境不同，处理方式随之不同。
当问题已定位清楚后，确定解决方案时，需要考虑用到什么环境和版本。重点关注:Release、RAC。
重点关注表格3
- Cursors/Session-每个session打开的游标数。当打开游标大于设置值时，会有ora_1000错误，解决之类问题：优化SQL、改大游标值。
SQL> show parameter open_cursors;
NAME TYPE VALUE
open_cursors integer 300
SQL> ALTER SYSTEM SET open_cursors=300 SCOPE=MEMORY;
- DBTime 在这个时间段里所有进程消耗时间的总和，数值越大 oracle越忙，如果DB Time远远小于Elapsed时间，则说明数据库比较空闲。
DB TIME=
DB cpu + Non-Idle Wait + Wait on CPU queue
干活时间+非空闲等待(IO、内存、网络)+等待有空闲CPU的时间
AAS= DB time /Elapsed Time ---(值越大越忙)
某个时间点上占用CPU或者处于非空闲等待的session 称之为活跃
举例：2个CPU，2个session，无空闲等待，都在干活，工作了60分钟，DBtime=602=120 ，AAS=120/60=2
2个CPU，3个session，无空闲等待，都在干活，工作了60分钟
DBtime=602 + Wait On CPU queue(60)=180 ，AAS=180/60=3
3.2 摘要报告
摘要报告中8个表格，分别为Cache Sizes、Load Profile、Instance Efficiency Percentages (Target 100%) 、Shared Pool Statistics 、Top 5 Timed Foreground Events、Host CPU (CPUs: 24 Cores: 12 Sockets: 2) 、Instance CPU 、Memory Statistics ，重点关注：Top 5 Timed Foreground Events和Load Profile。
- Top 5 Timed Foreground Events
在调优时，我们期望用最少时间/改动最小-达到最大的效益。Top 5 Timeed Foreground Events.jpg
DB CPU：不是等待事件是工作时间。
direct path read 等待事件分析
情况1：大量的磁盘排序操作，无法在排序区中完成排序，需要利用temp表空间进行排序。
情况2：大量的Hash Join操作，利用temp表空间保存hash区。
情况3：SQL语句的并行处理
情况4：大表的全表扫描，在Oracle11g中，全表扫描的算法有新的变化，根据表的大小、高速缓存的大小等信息，决定是否绕过SGA直接从磁盘读取数据。
因In-memory Sort %:100% 则排除情况1，不存在磁盘排序。
在实例活动统计table scans (direct read) 39,001、table scans (long tables) 45,886 ，85%表使用的是直接路径读取(物理读)，因此可判断出情况4引起该问题的原因。
在load Profile中Physical reads(物理读): 14,179.6
每秒磁盘读IO=14,179.6*8/1024=110M ，IO很繁忙，可能引起数据库性能下降。
找到具体SQL后，就是优化的事情啦，这里不做阐述。
** log file sync**
等待时间发生在redo log从log buffer写入到redo log期间。
正常情况下，log file sync的平均等待时间是小于5ms的，这里是297ms。 引起redo log的是DML语句，需关注user commit。  引用tanel Poder的图 
log file parallel write 也高时，通常是物理磁盘IO的问题。
情况1：频繁提交
处理方式：消除不必要的提交，事务要么全部成功，要么全部失败
情况2： 缓慢的I/O系统
处理方式：较高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待时间。将日志文件放裸设备上或绑定在RAID 0或RAID 0+1中，而不是绑定在RAID 5中。
情况3：过大的日志缓冲区
过大的日志缓冲区也可能延长log file sync等待。大型的日志缓冲区减少后台写入的数量，允许LGWR变得懒惰，并导致更多的重做条目堆积在日志缓冲区中。同时可以调整参数_LOG_IO_SIZE参数，其默认值是LOG_BUFFER的1/3或1MB，取两者之中较小的值。换句话说，你可以具有较大的日志缓冲区，但较小的_LOG_IO_SIZE将增加后台写入，从而减少log file sync的等待时间。
- load Profile
显示数据库负载信息，将它和基线数据时更具有参考价值，两者相比较，如每秒或每事务的负载变化不大，说明应用运行比较稳定。单个数据并没有一个所谓“正确”的值，会有些经验值/参考值，如Logons大于每秒1~2个、Hard parses大于100、全部parses超过每秒300表明可能有争用问题。
redo size 单位byte，1M以上表示繁忙。用途：估算DML量、估算单个事务的大小和频率-当单个事务的数据量大时可能是OLAP。Load Profile.jpg
因数据库是先写redo日志再操作的，当日志量太大时就会来不及写，会出现checkpoint not complete，此时增加redo数量和加大切换量能起到缓解作用。
增加IO速度：在log file sync的错误时 可能原因数据文件和redo log 在同一磁盘，导致IO下降。
硬解析过程
1)语法分析
2)权限与对象检查
3)是否在shared_pool 中存在
---3.1) 存在跳过4和5，直接运行，为软解析
---3.2)不存在则执行4和5，为硬解析
选择执行计划(相当昂贵的开销、为每个执行计划执行cost,比较哪个合适)
-
产生执行计划
解决方式：绑定变量逻辑读: 消耗的是CPU资源，物理读：消耗的是IO资源
- 总结
awr是一个性能数据统计的工具，但不提供具体方法，重在通过数据去发现问题，只有定位到具体SQL，才会有调优的方向。
可以结合其他监控如top、iotop初步判断是cpu还是io问题，再用awr针对性去找问题。
