Oracle的AWR报告分析 Oracle的AWR报告分析

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很重要的一点就是，减小逻辑读和物理读

如何生成awr报告：

* 1：登录对应的数据库服务器
2：找到oracle磁盘空间（d:oracle\product\10.2.0\db_1\RDBMS\Admin)
3：执行cmd-cd d:回车
4: cd d:oracle\product\10.2.0\db_1\RDBMS\Admin 回车
5：sqlplus 用户名/密码@服务链接名(例：sqlplus carmot_esz_1/carmot@igrp)
6：执行@awrrpt.sql 回车

第一步输入类型： html
第二步输入天数： 天数自定义（如1，表明当天，若是2，表明今天和昨天。。。）
第三步输入开始值与结束值：（你能够看到上面列出的数据，snap值）
这个值输入开始，与结束
第四步输入导出表的名称：名称自定义 回车
第五步，由程序自动导完。

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

具体分析过程： 

* 在分析awr报告以前，首先要肯定咱们的系统是属于oltp，仍是olap（数据库在安装的时候，选择的时候，会有一个选项，是选择oltp，仍是olap）
对于不一样的系统，性能指标的侧重点是不同的，好比，library hit和buffer hit，在olap系统中几乎能够忽略这俩个性能指标，而在oltp系统中，这俩个指标就很是关键了

* 首先要看俩个时间
Elapsed: 240.00 (mins) 代表采样时间是240分钟，任何数据都要经过这个时间来衡量，离开了这个采样时间，任何数据都毫无疑义
DB Time: 92,537.95 (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-99.30=0.7，说明花费在解析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毫秒，并且频率也是最高的，有95.9%，等待类别是并发
这里有一个概念：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
里面列出了每秒，每一个事务所产生的日志，逻辑读和物理读等指标

 

转自：http://www.cnblogs.com/liu-ke/p/4283509.html