一、是什么：AWR (Automatic Workload Repository) 是自动负载信息库的英文缩写，AWR报告是Oracle 10g以后版本提供的一种性能收集和分析工具，能提供一个时间段内整个系统资源使用情况的报告，通过报告可以了解一个系统的整个运行情况，生成的报告包括多个部分。
AWR每小时对v a c t i v e s e s s i o n h i s t o r y 视 图 ( 内 存 中 的 A S H 采 集 信 息 ， 理 论 为 1 小 时 ) 进 行 采 样 一 次 ， 并 将 信 息 保 存 到 磁 盘 中 ， 并 且 保 留 7 天 ， 7 天 后 旧 的 记 录 才 会 被 覆 盖 。 这 些 采 样 信 息 被 保 存 在 w r h active_session_history视图(内存中的ASH采集信息，理论为1小时)进行采样一次，并将信息保存到磁盘中，并且保留7天，7天后旧的记录才会被覆盖。这些采样信息被保存在wrh activesessionhistory视图(内存中的ASH采集信息，理论为1小时)进行采样一次，并将信息保存到磁盘中，并且保留7天，7天后旧的记录才会被覆盖。这些采样信息被保存在wrh_active_session_history视图(写入AWR库中的ASH信息，理论为1小时以上)中。而这个采样频率（1小时）和保留时间（7天）是可以根据实际情况进行调整的，这就给DBA们提供了更加有效的系统监测工具。
二、什么情况下用
DBA对数据库运行状态及状况的监控了解、测试过程中发现数据库出现瓶颈但无法定位到具体原因时，可以借用AWR报告进行分析定位。
数据库出现性能问题，一般都在三个地方：IO、内存、CPU，这三个地方又是息息相关的。假设这个三个地方都没有物理上的故障，当IO负载增大时，肯定需要更多的内存来存放，同时也需要CPU花费更多的时间来过滤这些数据。相反，CPU时间花费多的话，有可能是解析SQL语句，也可能是过滤太多的数据，倒不一定是和IO或内存有关系。
CPU：解析SQL语句，尝试多个执行计划，最后生成一个数据库认为是比较好的执行计划，但不一定是最优的。因为关联表太多的时候，数据库并不会穷举所有的执行计划，这会消耗太多的时间，oracle怎么知道这条数据是你要的，另一个就不是你要的呢，这是需要cpu来过滤的。
内存：SQL语句和执行计划都需要在内存保留一段时间，还有取到的数据，根据LRU算法也会尽量在内存中保留，在执行SQL语句过程中，各种表之间的连接，排序等操作也要占用内存。
IO：如果需要的数据不在内存中，则需要到磁盘中去取，就会涉及到物理IO了，还有表之间的连接数据太多，以及排序等操作内存放不下的时候，需要用到临时表空间，也会消耗物理io了。
这里说明下，ORACLE分配的内存中PGA一般只占20%，对于专用服务器模式，每次执行SQL语句、表数据的运算等操作，都在PGA中进行的，也就是说只能用ORACL分配内存的20%左右，如果多个用户都执行多表关联，而且表数据又多，再加上关联不当的话，内存就成为瓶颈了，所以优化SQL很重要的一点就是，减少逻辑读和物理读。
三、如何生成awr报告
1、登录ORACLE数据库服务器，记住当前目录或者切换至AWR想要保存的目录；
cd 到要生成的目录
2、SQLplus 用户名/密码@服务连接名，连接oracle数据库实例
sqlplus / as sysdba
3、执行@?/rdbms/admin/awrrpt; 会出现提示，
可以生成以下几种类型AWR报告，大部分情况下都是生成本实例的AWR报告
@?/rdbms/admin/awrrpt; 本实例AWR包括
@?/rdbms/admin/awrrpti; RAC中选择实例号
@?/rdbms/admin/awrddrpt; AWR 比对报告
@?/RDBMS/admin/awrgrpt; RAC全局AWR报告
注：exec dbms_workload_repository.create_snapshot(); 可自己执行生成快照点
四、分析AWR报告
下面我们来看一份AWR报告：
在Top 10 Foreground Events by Total Wait Time中我们可以看到等待耗时的前10位：
本例中看，可能内存回收gc出问题了，平均等待耗时需要45s。
在SQL ordered by Elapsed Time中，我们可以看到一些慢查询，分析慢查询的执行计划也是解决这个问题的一种方案。
我们看到，慢查询的时间很长，达到了上百秒。
除此之外，AWR报告还提供了很多信息，通过报告我们能分析数据库存在的问题，为如何优化提供了一定的方向。