如何获取oracle awr 报告_工具

1 登录Oracle用户

2 进入 SQLplus ,扫行 @awrrptsql 这里注意,要指定 awrrptsql脚本路径,所以建议一开始就进到指定目录这样方便些

cd /u01/app/oracle/product/1120/db_1/rdbms/admin/

这里有个小技巧, admin下有很多脚本,用于生成不出的报告, 比如 ashrptsql 用于生成 ASH报告文件名是用报告名称缩写+rptsql 方式命名的

3 指定报告格式和时间范围,这里分四次输入

第一次指定格式,这里使用html格式

第二次指定日期范围,这里选当天的注意了,因为这些数据占空间较大,一般不建议保留太久我们这边保留了两天的

第三次指定时间段

第四次指定文件名

最后很多人都会注意到在 SSH 下输入命令,一旦输入错误,没办法使用 Background 按键这是因为sqlplus编码格式的原因可以使用 ctrl+Background 的方式一次删两个字符将就着用

4 之后生成的文件以文件名+lst 的方式生成了直接用浏览器打开就行了

5 如果使用了数据库集群,那么任意哪个服务器上都能取到完整的AWR报告,因为数据是在集群中的

1生成单实例 AWR 报告：@$ORACLE_HOME/rdbms/admin/awrrptsql2生成 Oracle RAC AWR 报告：@$ORACLE_HOME/rdbms/admin/awrgrptsql3生成 RAC 环境中特定数据库实例的 AWR 报告:@$ORACLE_HOME/rdbms/admin/awrrptisql4生成 Oracle RAC 环境中多个数据库实例的 AWR 报告的方法：@$ORACLE_HOME/rdbms/admin/awrgrptisql5生成 SQL 语句的 AWR 报告：@$ORACLE_HOME/rdbms/admin/awrsqrptsql6生成特定数据库实例上某个 SQL 语句的 AWR 报告：@$ORACLE_HOME/rdbms/admin/awrsqrpisql--生成 AWR 时段对比报告7生成单实例 AWR 时段对比报告@$ORACLE_HOME/rdbms/admin/awrddrptsql9生成 Oracle RAC AWR 时段对比报告@$ORACLE_HOME/rdbms/admin/awrgdrptsql10生成特定数据库实例的 AWR 时段对比报告11生成 Oracle RAC 环境下特定（多个）数据库实例的 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中进行的，也就是说只能用16G左右的内存，如果多个用户都执行

多表关联，而且表数据又多，再加上关联不当的话，内存就成为瓶颈了，所有优化sql很重要的一点就是，减少逻辑读和物理读

如何生成awr报告：

1：登陆对应的数据库服务器

2：找到oracle磁盘空间（d:oracle\product\1020\db_1\RDBMS\Admin)

3：执行cmd-cd d:回车

4: cd d:oracle\product\1020\db_1\RDBMS\Admin 回车

5：sqlplus 用户名/密码@服务连接名(例：sqlplus carmot_esz_1/carmot@igrp)

6：执行@awrrptsql 回车

第一步输入类型： html

第二步输入天数：天数自定义（如1，代表当天，如果2，代表今天和昨天。。。）

第三步输入开始值与结束值：（你可以看到上面列出的数据，snap值）

这个值输入开始，与结束

第四步输入导出表的名称：名称自定义回车

第五步，由程序自动导完。

第六：到d:oracle\product\1020\db_1\RDBMS\Admin 目录下。找到刚才生成的文件。 XXXXLST文件

具体分析过程：

在分析awr报告之前，首先要确定我们的系统是属于oltp，还是olap（数据库在安装的时候，选择的时候，会有一个选项，是选择oltp，还是olap）

对于不同的系统，性能指标的侧重点是不一样的，比如，library hit和buffer hit，在olap系统中几乎可以忽略这俩个性能指标，而在oltp系统中，这俩个指标就非常关键了

首先要看俩个时间

Elapsed: 24000 (mins) 表明采样时间是240分钟，任何数据都要通过这个时间来衡量，离开了这个采样时间，任何数据都毫无疑义

DB Time: 92,53795 (mins) 表明用户 *** 作花费的时候，包括cpu时间喝等待时间，也许有人会觉得奇怪，为什么在采样的240分钟过程中，用户 *** 作时间竟然有92537分钟呢，远远超过了

采样时间，原因是awr报告是一个数据的集合，比如在一分钟之内，一个用户等待了30秒，那么10个用户就等待了300秒，对于cpu的话，一个cpu处理了30秒，16个cpu就是4800秒，这些时间都是以累积的方式记录在awr报告中的。

再看sessions，可以看出连接数非常多

为了对数据库有个整体的认识，先看下面的性能指标

1 Buffer Nowait 说明在从内存取数据的时候，没有经历等待的比例，期望值是100%

2 Buffer Hit 说明从内存取数据的时候，buffer的命中率的比例，期望值是100%，但100%并不代表性能就好，因为这只是一个比例而已，举个例子，执行一条 sql语句，# 执行计划是需要取10000个数据块，结果内存中还真有这10000个数据块，那么比例是100%，表面上看是性能最高的，还有一个执行计划是需要500 个数据块，内存中有250个，另外250个需要在物理磁盘中取，

这种情况下，buffer hit是50%，结果呢，第二个执行计划性能才是最高的，所以说100%并不代表性能最好

3 Library Hit 说明sql在Shared Pool的命中率，期望值是100%

4 Execute to Parse 说明解析sql和执行sql之间的比例，越高越好，说明一次解析，到处执行，如果parse多，execute少的话，还会出现负数，因为计算公式是100（1-parse/execute）

5 Parse CPU to Parse Elapsd 说明在解析sql语句过程中，cpu占整个的解析时间比例，，期望值是100%，说明没有产生等待，需要说明的是，即使有硬解析，只要cpu没有出现性能问题，也是可以容忍的，比较硬解析也有它的好处的

6 Redo NoWait 说明在产生日志的时候，没有产生等待，期望值是100%

7 Soft Parse 说明软解析的比例，期望值是100%，有一点要说明的是，不要单方面的追求软解析的高比例，而去绑定变量，要看性能的瓶颈在哪里

8 Latch Hit 说明latch的命中率，期望值是100%，latch类似锁，是一种内存锁，但只会产生等待，不会产生阻塞，和lock还是有区别的，latch是在并发的情况下产生的

9 Non-Parse CPU 说明非解析cpu的比例，越高越好，用100减去这个比例，可以看出解析sql所花费的cpu，100-9930=07，说明花费在解析sql上的cpu很少

结合Time Model Statistics

可以看出，在整个sql执行时间（sql execute elapsed time）时间为5552019秒中，解析时间（parse time elapsed）用了36秒，硬解析时间（hard parse elapsed time）用了34秒虽然硬解析时间占了整个解析时间的绝大部分，但解析时间是花的很少的，所以可以判断出，sql的解析没有成为性能的瓶颈，进一步推测，sql在获取数据的过程中遇到了瓶颈

继续看Top 5 Timed Events，从这里可以看出等待时间在前五位的是什么事件，基本上就可以判断出性能瓶颈在什么地方

1 buffer busy waits 说明在获取数据的过程中，频繁的产生等待事件，很有可能产生了热点块，也就是说，很多会话都去读取同样的数据块，这一事件等待了5627394次，总共等待了5322924秒，平均等待时间为946毫秒，而且频率也是最高的，有959%，等待类别是并发

这里有一个概念：oracle *** 作的最小单位是块，当一个会话要修改这个块中的一条记录，会读取整个块，如果另一个会话要修改的数据也正好在这个块中，虽然这俩个

2 会话修改的记录不一样，也会产生等待direct path write temp和direct path read temp 说明用到了临时表空间，那我们再看一下Tablespace IO Stats

各项指标都是非常高的，再根据上面的In-memory Sort是100%，没有产生磁盘排序，也就在排序的时候没有用到临时表空间，进一步推测，多个session，每个session执行的sql语句中多表关联，产生了很多中间数据，pga内存中放不下，

用到了临时表空间，也有可能是用到了lob字段，在用lob字段的时候，也会用到临时表

继续看SQL Statistics

根据buffer busy waits等待次数，时间，频率都是最高的，我们重点看逻辑读，物理读，和执行时间最长的sql，把排在前几位的拿出来优化

优化的原则为降低物理读，逻辑读，sql语句中的子 *** 作执行次数尽量少，在看oracle估计出来的执行计划是看不出子 *** 作的执行次数的，要看运行时的执行计划

有兴趣的话还可以看一下Segment Statistics

列出了用到的索引和表的使用情况，从这里也能看出索引和表的使用频率

也可以看一下Load Profile

里面列出了每秒，每个事务所产生的日志，逻辑读和物理读等指标

1、首先使用VMVARE10搭建一个redhat65的虚拟机。

2、在虚拟redhat65上安装ORACLE11G的数据库。

3、使用oewizard导入测试数据，可以根据向导提示进行数据导入。

4、使用swingbench进行压力测试。

测试步骤：

1、导数据之前需要修改temp表空间大小，使其能够容纳下相应的导入数据

create temporarytablespace temp tempfile '/home/oracle/oradata/orcl/tempdbf' size 1g;

alter databasedefault temporary tablespace temp;

2、安装swingbench测试软件，直接解压缩即可运行。

unzip -x swingbench25919zip

3、进入swingbench/bin目录执行oewizard导入1G测试数据，并修改数据库连接名和DBA密码

wKioL1Qx2h3TrIIGAAGyVq92CVA180jpg

输入导入数据文件存放位置：

wKiom1Qx2nGTFbZFAAGBnRUybxU038jpg

选择导入1G数据：

wKioL1Qx2tnyThWoAAE8qLLgIJI464jpg

数据导完之后在该目录下运行swingbench执行测试，修改数据库连接名，用户连接数设置为300，测试时间设置为10分钟

wKiom1Qx2v6S6yjvAAKAl63J5mg784jpg

修改Distributed Controls用于测试过程中搜集测试监控信息，修改完之后测试连接是否正常，并可以统计主机的cpu disk IO 信息

wKioL1Qx24DDSssqAAFmiLc2VSU132jpg

还可以拉出AWR报表

wKioL1Qx3O2gzw45AADH_p4CEeQ979jpg

设置 insert，update ，select的比例

wKioL1Qx3RHB32ITAAEK9ABjiPI261jpg

设置完成之后，点击左上角绿色按钮执行测试

wKiom1Qx24zgsNQ-AAEJ51YcKSs614jpg

wKiom1Qx3QaxFssnAAGpJeiYV6Q924jpg

测试结果可保持为XML文档，