【linux】 Oracle AWR 报告的生成和分析

* 定义：awr报告是oracle 10g下提供的一种性能收集和分析工具，它能提供一个时间段内整个系统资源使用情况的报告，通过这个报告，我们就可以了解一个系统的整个运行情况，这就像一个人全面的体检报告。

如何分析：

* 在看awr报告的时候，我们并不需要知道所有性能指标的含义，就可以判断出问题的所在，这些性能指标其实代表了oracle内部实现，对oracle理解的越深，在看awr报告的时候，对数据库性能的判断也会越准确

* 在看性能指标的时候，心里先要明白，数据库出现性能问题，一般都在三个地方，io，内存，cpu，这三个又是息息相关的（ps：我们先假设这个三个地方都没有物理上的故障），当io负载增大时，肯定需要更多的内存来存放，同时也需要cpu花费更多的时间来过滤这些数据，相反，cpu时间花费多的话，有可能是解析sql语句，也可能是过滤太多的数据，到不一定是和io或内存有关系了

* 当我们把一条sql送到数据库去执行的时候，我们要知道，什么时候用到cpu，什么时候用到内存，什么时候用到io

1. cpu：解析sql语句，尝试多个执行计划，最后生成一个数据库认为是比较好的执行计划，不一定是最优的，因为关联表太多的时候，数据库并不会穷举所有的执行计划，这会消耗太多的时间，oracle怎么就知道这条数据时你要，另一个就不是你要的呢，这是需要cpu来过滤的
2. 内存：sql语句和执行计划都需要在内存保留一段时间，还有取到的数据，根据lru算法也会尽量在内存中保留，在执行sql语句过程中，各种表之间的连接，排序等操作也要占用内存
3. io：如果需要的数据在内存中没有，则需要到磁盘中去取，就会用到物理io了，还有表之间的连接数据太多，以及排序等操作内存放不下的时候，也需要用到临时表空间，也就用到物理io了

这里有一点说明的是，虽然oracle占用了8G的内存，但pga一般只占8G的20%，对于专用服务器模式，每次执行sql语句，表数据的运算等操作，都在pga中进行的，也就是说只能用1.6G左右的内存，如果多个用户都执行
多表关联，而且表数据又多，再加上关联不当的话，内存就成为瓶颈了，所有优化sql很重要的一点就是，减少逻辑读和物理读

 

2.AWR 报告的生成

2.1.手工刷出快照

默认情况下 Oracle 的快照每一小时生成一次，也就是说 AWR 分析的是一小时以内这一段时间的负载情况。
用这个默认的不够灵活，而且浪费调试时间——我们总不能压一小时才能看结果吧？一般取压力高峰时的两个快照之间的几分钟就可以了。
数据库 DBA 用户登录 SQL shell(或者直接用 Oracle 客户端打开 sql 执行窗，如 SQL Developer)，执行以下 sql：
SQL> exec dbms_workload_repository.create_snapshot();
匿名块已完成
隔几分钟后再执行一次，生成俩快照。
这个间隔时间越长约好，越能说明问题。

2.2.以系统 DBA 登录 SQL shell

SSH 登录远程 Oracle 所在 Redhat 主机，依次执行以下命令以登录 SQL shell：
# export ORACLE_HOME=/u01/oracle/product/10.2.0/db_1
# export oracle_sid=defonds
# cd /u01/oracle/product/10.2.0/db_1/bin
# ./sqlplus sys/sysdefonds@defonds as sysdba
SQL>
登录 SQL shell 成功。
注：/u01/oracle/product/10.2.0/db_1/ 是为 Oracle 安装路径。

2.3.生成 AWR 报告

SQL> @/u01/oracle/product/10.2.0/db_1/rdbms/admin/awrrpt.sql
进入 AWR 操作步骤：

Enter value for report_type 输入 html：

我们看当天的，Enter value for num_days 输入 1：

如上图所示，列出的是当天生成的所有快照，可以看到：ID 为 27810 和 27811 的两个是我们刚才手工生成的，我们就用 AWR 采集这两个快照之间的数据了。因此 Enter value for begin_snap 我们输入 27810：

Enter value for end_snap 我们输入 27811：

报告名字我们就用默认的 awrrpt_1_27810_27811.html 即可，直接回车，awr 报告生成：

生成的文件就在 /u01/oracle/product/10.2.0/db_1/bin/ 目录下：

3.AWR报告分析

可以直接跳到 SQL ordered by Elapsed Time 查看 SQL 排行榜：

如上表所示，top1 是 T_DFON_SINOPAY_STATDAY 表的修改操作，它占据了 99.98% 的数据库时间；
top2 是针对 T_DFON_SINOPAY_STATDAY 表的一个统计操作。
据此基本可以判定发生了行锁定，导致性能提不上去，Top 5 Timed Events 证实了这一点：