Oracle AWR报告的生成和分析

我就是我 2021-09-02 09:12 367阅读 0赞

一、是什么：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报告

参考：[参考1][1][参考2][2]

下面我们来看一份AWR报告：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center]  
在Top 10 Foreground Events by Total Wait Time中我们可以看到等待耗时的前10位：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 1]  
本例中看，可能内存回收gc出问题了，平均等待耗时需要45s。

在SQL ordered by Elapsed Time中，我们可以看到一些慢查询，分析慢查询的执行计划也是解决这个问题的一种方案。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 2]  
我们看到，慢查询的时间很长，达到了上百秒。  
除此之外，AWR报告还提供了很多信息，通过报告我们能分析数据库存在的问题，为如何优化提供了一定的方向。

[1]: https://cnodejs.org/topic/57f8a9a48489e7ca69f4e8a1
[2]: https://blog.csdn.net/defonds/article/details/52958303
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center]: /images/20210518/966340dfdeb14fb59d68ebd3a90ac43e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20210518/e14de90e3390469dbadadc372df1be39.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20210518/8bbebf06d6784aa293041e152609c445.png