AWR
存储位置：SYSAUX表空间，详细信息视图dba_hist_snapshot
存储策略：60分钟一个，存七天
用途：AWR并不像其他V$视图或者表一样诊断实时问题，只是用来诊断历史性能问题。
比如数据库响应慢、大量等待事件、慢SQL（历史）等等问题，报告很长，我们可以关注其中
一部分来快速定位问题。
如果当前某个SQL执行缓慢，应该通过生成相应SQL的执行计划去解决。
AWR生成建议
1、建议生成多个AWR报告：性能好的情况下，和出问题的情况下，进行对比发现问题。
2、时间段选择：如果今天上午十点到下午两点数据库响应慢，则我们需要出上午十点
到下午两点这四个小时的AWR。
3、分段出AWR：根据上午十点到下午两点的AWR，我们可以再分为四个AWR，四个AWR
共同显示的问题，应该着重关注。隔离掉不必要的问题。
分析步骤
1、数据库详细信息
当我们拿到一个AWR的时候，首先看是否是RAC，我们的实例显示为RAC=NO
2、查看主机配置信息
如果我们出性能正常和性能问题这两个时间段的AWR，注意看有没有内存和CPU数量的变化
3、快照详细信息
Elapsed：快照生成时间段总时间
DB Time：消耗在数据库上的会话时间。不包括Oracle后台进程消耗的时间
当我们有多个活动会话的时候，DB Time就可能比Elapsed更大，我们需要确认Snap Time的时间段是否是出性能问题的时间段。
4、负载信息
有几个信息需要我们关注
首先“DB CPU(s)”每秒，我们来了解一下“DB CPU”。如果我们操作系统是8 Core的，每秒钟我们有8的CPU，而图中只用了0.1.,所以CPU不是瓶颈。
然后我们看Parse（解析或者说是软解析）和hard Parse（硬解析），我们关注软解析和硬解析的比例，如果硬解析相对于软解析更高，我们就需要检查下cursor_sharing,或者检查我们的sql语句是否使用绑定变量.图中硬解析/软解析的比例很低，没有硬解析的问题。通常硬解析问题是由于不正确的绑定变量使用或者内存问题。
5、影响实例百分比
个人关注的比较少。
6、前十后台等待事件，按照总等待事件倒序。
我们排查性能问题着重需要关注的模块，这块超级重要，其中的信息会表现出我们系统的瓶颈所在。
首先我们关注“wait class”，如果是user I/O或者system I/O，这样有可能是正常的，如果”wait class”是“Concurrency”，那就可能是比较严重的问题。然后关注“total wait time（sec）”，等待的总时长，就是总的等待时长，如果total wait time很大但是wait avg很小，应该也不是什么问题。
如果都很高，我们就需要多加关注。
图片中我们91%的DB time都用于log file sync，并且wait class是commit。我们可以关注下日志的相关设置是否合理。
7、共享池统计信息
理论上，一个长时间运行的数据库，memory usage% 应该维持在70%左右，如果这个值太小，说明我们的内存浪费了，图片中使用了50% 。
如果memory usage% 大于90%，我们的某些PL/SQL、cursor等的运行就有可能出问题，应该考虑扩展数据库可使用内存，或者检查内存是否合理使用。
%SQL with execution>1 表明sql执行次数大于1的比例，表示程序是否有复用sql，sql有没有使用绑定变量。
8、 Time Model Statistics
详细说明系统资源使用情况，按照 db time百分比排序
总的% of DB time 可能大于100%，因为sql_execute_elapset_time可能包含hard_parse和parse的时间，所以会有大于100%的情况出现。 我们主要关注DB time消耗百分比较高的事件名称。
9、操作系统统计信息。
就是系统资源使用情况。
负载，CPU和IO的使用情况
10、top sql的统计信息（很重要）
根据执行计划中各种资源的使用情况进行列出各类资源占用最高的sql。
11、 SQL Ordered by Elapsed Time
解析时间长执行次数少的，我们需要进行sql优化。
如果executions是0，说明sql正在执行时生成了AWR快照。
11、 SQL Ordered by CUP Time
根据耗费cpu时间做的排序，当cpu有瓶颈时，查看或者调整相应的sql。