OracleAWR性能分析报告深度解读 Oracle中的AWR,全称为AutomaticWorkloadRepository,自动负载信息库。它收集关于特定数据库的操作统计信息和其他统计信息,Oracle以固定的时间间隔(默认为1个小时)为其所有重要的统计信息和负载信息执行一次快照,并将快照存放入AWR中。这些信息在AWR中保留指定的时间(默认为1周),然后执行删除。执行快照的频率和保持时间都是可以自定义的。 AWR的引入,为我们分析数据库提供了非常好的便利条件(这方面MySQL就相差了太多)。曾经有这样的一个比喻——“一个系统,就像是一个黑暗的大房间,系统收集的统计信息,就如同放置在房间不同位置的蜡烛,用于照亮这个黑暗大房间。Oracle,恰到好处地放置了足够的蜡烛(AWR),房间中只有极少的烛光未覆盖之处,性能瓶颈就容易定位。而对于蜡烛较少或是没有蜡烛的系统,性能优化就如同黑暗中的舞者。” 那如何解读AWR的数据呢?Oracle本身提供了一些报告,方便进行查看、分析。下面就针对最为常见的一种报告——《AWR数据库报告》进行说明。希望通过这篇文章,能方便大家更好地利用AWR,方便进行分析工作。 一、MAIN 1DatabaseInformation 2SnapshotInformation (1)Sessions 表示采集实例连接的会话数。这个数可以帮助我们了解数据库的并发用户数大概的情况。这个数值对于我们判断数据库的类型有帮助。 (2)Cursors/session 每个会话平均打开的游标数。 (3)Elapsed 通过Elapsed/DBTime比较,反映出数据库的繁忙程度。如果DBTime>>Elapsed,则说明数据库很忙。 (4)DBTime 表示用户操作花费的时间,包括CPU时间和等待事件。通常同时这个数值判读数据库的负载情况。 具体含义 dbtime=cputime+waittime(不包含空闲等待)(非后台进程) *dbtime就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间。对应于V$SESSION的elapsed_time字段累积。 "合集数据" 需要注意的是AWR是一个数据合集。比如在1分钟之内,1个用户等待了30秒钟,那么10个用户等待事件就是300秒。CPU时间也是一 样,在1分钟之内,1个CPU处理30秒钟,那么4个CPU就是120秒。这些时间都是以累积的方式记录在AWR当中的。 示例 DBCPU——这是一个用于衡量CPU的使用率的重要指标。假设系统有N个CPU,那么如果CPU全忙的话,一秒钟内的DBCPU就是N秒。除了利用CPU进行计算外,数据库还会利用其它计算资源,如网 络、硬盘、内存等等,这些对资源的利用同样可以利用时间进行度量。假设系统有M个session在运行,同一时刻有的session可能在利用CPU,有的session可能在访问硬盘,那么在一秒钟内,所有session的时间加起来就可以表征系统在这一秒内的繁忙程度。一般的,这个和的最大值应该为M。这其实就是Oracle提供的另一个重要指标:DBtime,它用以衡量前端进程所消耗的总时间。 对除CPU以后的计算资源的访问,Oracle用等待事件进行描述。同样地,和CPU可分为前台消耗CPU和后台消耗CPU一样,等待事件也可以分为前台等待事件和后台等待事件。DBTime一般的应该等于"DBCPU+前台等待事件所消耗时间"的总和。等待时间通过v$system_event视图进行统计,DBTime和DBCPU则是通过同一个视图,即v$sys_time_model进行统计。 --"LoadProfile"中关于DBTime的描述 *这个系统的CPU个数是8,因此我们可以知道前台进程用了系统CPU的7.1/8=88.75%。DBTime/s为11.7,可以看出这个系统是CPU非常繁忙的。里面CPU占了7.1,则其它前台等待事件占了11.7–7.1= 4.6WaitTime/s。DBTime占DBCPU的比重:7.1/11.7=60.68% --"Top5TimedEvents"中关于DBCPU的描述 按照CPU/等待事件占DBTime的比例大小,这里列出了Top5。如果一个工作负载是CPU繁忙型的话,那么在这里应该可以看到DBCPU的影子。 *注意到,我们刚刚已经算出了DBCPU的%DBtime,60%。其它的externaltableread、directpathwrite、PXDeq:readcredit、PXDeq:SlaveSessionStats这些就是占比重40的等待事件里的Top4了。 --"Top5TimedForegroundEvents"的局限性 再研究下这个Top5TimedForegroundEvents,如果先不看LoadProfile,是不能计算出一个CPU-Bound的工作负载。要知道系统CPU的繁忙程序,还要知道这个AWR所基于两个snapshot的时间间隔,还要知道系统CPU的个数。要不系统可以是一个很IDLE的系统呢。记住CPU利用率=DBCPU/(CPU_COUNT*ElapsedTIME)。这个Top 5给我们的信息只是这个工作负载应该是并行查询,从外部表读取数据,并用insertappend的方式写入磁盘,同时,主要时间耗费在CPU的运算上。 --解读"DBTime">"DBCPU"+"前台等待事件所消耗时间"——进程排队时间 上面提到,DBTime一般的应该等于DBCPU+前台等待事件所消耗时间的总和。在下面有对这三个值的统计: DBCPU=6474.65 DBTIME=10711.2 FGWaitTime=1182.63 明显的,DBCPU+FGWaitTime<DBTime,只占了71.5% *其它的28.5%被消耗到哪里去了呢?这里其实又隐含着一个Oracle如何计算DBCPU和DBTime的问题。当CPU很忙时,如果系统里存在着很多进程,就会发生进程排队等待CPU的现象。在这样,DBTIME是把进程排队等待CPU的时间算在内的,而DBCPU是不包括这一部分时间。这是造成DBCPU+FGWaitTime<DBTime的一个重要原因。如果一个系统CPU不忙,这这两者应该就比较接近了。不要忘了在这个例子中,这是一个CPU非常繁忙的系统,而71.5%就是一个信号,它提示着这个系统可能是一个CPU-Bound的系统。 二、ReportSummary1CacheSizes 这部分列出AWR在性能采集开始和结束的时候,数据缓冲池(buffercache)和共享池(sharedpool)的大小。通过对比前后的变化,可以了解系统内存消耗的变化。 2LoadProfile 这两部分是数据库资源负载的一个明细列表,分隔成每秒钟的资源负载和每个事务的资源负载。 Redosize 每秒(每个事务)产生的日志大小(单位字节) Logicalreads 每秒(每个事务)产生的逻辑读(单位是block)。在很多系统里select执行次数要远远大于transaction次数。这种情况下,可以参考Logicalreads/Executes。在良好的oltp环境下,这个应该不会超过50,一般只有10左右。如果这个值很大,说明有些语句需要优化。 BlockChanges 每秒(每个事务)改变的数据块数。 Physicalreads 每秒(每个事务)产生的物理读(单位是block)。一般物理读都会伴随逻辑读,除非直接读取这种方式,不经过cache。 Physicalwrites 每秒(每个事务)产生的物理写(单位是block)。 Usercalls 每秒(每个事务)用户调用次数。Usercalls/Executes基本上代表了每个语句的请求次数,Executes越接近Usercalls越好。 Parses 每秒(每个事务)产生的解析(或分析)的次数,包括软解析和硬解析,但是不包括快速软解析。软解析每秒超过300次意味着你的"应用程序"效率不高,没有使用softsoftparse,调整session_cursor_cache。 Hardparses 每秒(每个事务)产生的硬解析次数。每秒超过100次,就可能说明你绑定使用的不好。 Sorts 每秒(每个事务)排序次数。 Logons 每秒(每个事务)登录数据库次数。 Executes 每秒(每个事务)SQL语句执行次数。包括了用户执行的SQL语句与系统执行的SQL语句,表示一个系统SQL语句的繁忙程度。 Transactions 每秒的事务数。表示一个系统的事务繁忙程度。目前已知的最繁忙的系统为淘宝的在线交易系统,这个值达到了1000。 %BlockschangedperRead 表示逻辑读用于只读而不是修改的块的比例。如果有很多PLSQL,那么就会比较高。 Rollbackpertransaction% 看回滚率是不是很高,因为回滚很耗资源。 RecursiveCall% 递归调用SQL的比例,在PL/SQL上执行的SQL称为递归的SQL。 3InstanceEfficiencyPercentages(Target100%) 这个部分是内存效率的统计信息。对于OLTP系统而言,这些值都应该尽可能地接近100%。对于OLAP系统而言,意义不太大。因为在OLAP系统中,大查询的速度才是对性能影响的最大因素。 BufferNowait% 非等待方式获取数据块的百分比。 这个值偏小,说明发生SQL访问数据块时数据块正在被别的会话读入内存,需要等待这个操作完成。发生这样的事情通常就是某些数据块变成了热块。 BufferNowait<99%说明,有可能是有热块(查找x$bh的tch和v$latch_children的cachebufferschains)。 RedoNoWait% 非等待方式获取redo数据百分比。 BufferHit% 数据缓冲命中率,表示了数据块在数据缓冲区中的命中率。 BufferHit<95%,可能是要加db_cache_size,但是大量的非选择的索引也会造成该值很高(大量的dbfilesequentialread)。 In-memorySort% 数据块在内存中排序的百分比。总排序中包括内存排序和磁盘排序。当内存中排序空间不足时,使用临时表空间进行排序,这个是内存排序对总排序的百分比。 过低说明有大量排序在临时表空间进行。在oltp环境下,最好是100%。如果太小,可以调整PGA参数。 LibraryHit% 共享池中SQL解析的命中率。 LibraryHit<95%,要考虑加大共享池,绑定变量,修改cursor_sharing等。 SoftParse% 软解析占总解析数的百分比。可以近似当作sql在共享区的命中率。 这个数值偏低,说明系统中有些SQL没有重用,最优可能的原因就是没有使用绑定变量。 <95%:需要考虑到绑定 <80%:那么就可能sql基本没有被重用 ExecutetoParse% 执行次数对分析次数的百分比。 如果该值偏小,说明解析(硬解析和软解析)的比例过大,快速软解析比例小。根据实际情况,可以适当调整参数session_cursor_cache,以提高会话中sql执行的命中率。 round(100*(1-:prse/:exe),2)即(Execute次数-Parse次数)/Execute次数x100% prse=selectvaluefromv$sysstatwherename='parsecount(total)'; exe=selectvaluefromv$sysstatwherename='executecount'; 没绑定的话导致不能重用也是一个原因,当然sharedpool