Oracle_AWR报告指标全解析

@?/rdbms/admin/awrddrptAWR比对报告@?/rdbms/admin/awrgrptRAC全局AWR自动生成AWRHTML报告：、报告总结WORKLOADREPOSITORYreportforDBNameDBIdInstanceInstNumStartupTimeReleaseRAC------------------------------------------------------------------------MAC2629627371askmaclean.com122-Jan-1316:4911.2.0.3.0YESHostNamePlatformCPUsCoresSocketsMemory(GB)--------------------------------------------------------------------------MAC10AIX-BasedSystems(64-bit)12832320.00SnapIdSnapTimeSessionsCurs/Sess---------------------------------------------BeginSnap:585323-Jan-1315:00:563,5201.8EndSnap:585423-Jan-1315:30:413,7651.9Elapsed:29.75(mins)DBTime:7,633.76(mins)Elapsed为该AWR性能报告的时间跨度(自然时间的跨度，例如前一个快照snapshot是4点生成的，后一个快照snapshot是6点生成的，则若使用@?/rdbms/admin/awrrpt脚本中指定这2个快照的话，那么其elapsed=(6-4)=2个小时)，一个AWR性能报告至少需要2个AWRsnapshot性能快照才能生成(注意这2个快照时间实例不能重启过，否则指定这2个快照生成AWR性能报告会报错)，AWR性能报告中的指标往往是后一个快照和前一个快照的指标的delta，这是因为累计值并不能反映某段时间内的系统workload。DBTIME=所有前台session花费在database调用上的总和时间：注意是前台进程foregroundsessions包括CPU时间、IOTime、和其他一系列非空闲等待时间，别忘了cpuonqueuetimeDBTIME不等于响应时间，DBTIME高了未必响应慢，DBTIME低了未必响应快DBTime描绘了数据库总体负载，但要和elapsedtime逝去时间结合其他来。AverageActiveSessionAAS=DBtime/ElapsedTimeDBTime=60min，ElapsedTime=60minAAS=60/60=1负载一般DBTime=1min,ElapsedTime=60minAAS=1/60负载很轻DBTime=60000min，ElapsedTime=60minAAS=1000系统hang了吧？DBTIME=DBCPU+Non-IdleWait+WaitonCPUqueue如果仅有2个逻辑CPU，而2个session在60分钟都没等待事件，一直跑在CPU上，那么：DBCPU=2*60mins，DBTime=2*60+0+0=120AAS=120/60=2正好等于OSload2。如果有3个session都100%仅消耗CPU，那么总有一个要waitonqueueDBCPU=2*60mins，waitonCPUqueue=60minsAAS=(120+60)/60=3主机load亦为3，此时vmstat看waitingforruntime真实世界中？DBCpu=xxmins，Non-IdleWait=enq:TX+cursorpinSonX+latch:xxx+dbfilesequentialread+………..阿猫阿狗1-1内存参数大小CacheSizesBeginEnd~~~~~~~~~~~--------------------BufferCache:49,152M49,152MStdBlockSize:8KSharedPoolSize:13,312M13,312MLogBuffer:334,848K内存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target)小内存有小内存的问题，大内存有大内存的麻烦！ORA-04031???!!Buffercache和sharedpoolsize的begin/end值在ASMM、AMM和11gR2MSMM下可是会动的哦！这里说sharedpool一直收缩，则在shrink过程中一些rowcache对象被lock住可能导致前台rowcachelock等解析等待，最好别让sharedpoolshrink。如果这里sharedpool一直在grow，那说明sharedpool原有大小不足以满足需求(可能是大量硬解析)，结合下文的解析信息和SGAbreakdown来一起诊断问题。1-2LoadProfileLoadProfilePerSecondPerTransactionPerExecPerCall~~~~~~~~~~~~--------------------------------------------------DBTime(s):256.60.20.070.03DBCPU(s):3.70.00.000.00Redosize:1,020,943.0826.5Logicalreads:196,888.0159.4Blockchanges:6,339.45.1Physicalreads:5,076.74.1Physicalwrites:379.20.3Usercalls:10,157.48.2Parses:204.00.2Hardparses:0.90.0W/AMBprocessed:5.00.0Logons:1.70.0Executes:3,936.63.2Rollbacks:1,126.30.9Transactions:1,235.3%BlockschangedperRead:53.49RecursiveCall%:98.04Rollbackpertransaction%:36.57RowsperSort:73.70指标指标含义redosize单位bytes，redosize可以用来估量update/insert/delete的频率，大的redosize往往对lgwr写日志，和arch归档造成I/O压力，PerTransaction可以用来分辨是大量小事务，还是少量大事务。如上例每秒redo约1MB，每个事务800字节，符合OLTP特征LogicalRead单位次数*块数，相当于“人*次”，如上例196,888*db_block_size=1538MB/s，逻辑读耗CPU，主频和CPU核数都很重要，逻辑读高则DBCPU往往高，也往往可以看到latch:cachebufferchains等待。大量OLTP系统(例如siebel)可以高达几十乃至上百Gbytes。Blockchanges单位次数*块数，描绘数据变化频率单位次数*块数，如上例5076*8k=39MB/s，物理读消耗IO读，体现在IOPS和吞吐量等不同纬PhysicalRead度上；但减少物理读可能意味着消耗更多CPU。好的存储每秒物理读能力达到几GB，例如Exadata。这个physicalread包含了physicalreadscache和physicalreadsdirectPhysicalwrites单位次数*块数，主要是DBWR写datafile，也有directpathwrite。dbwr长期写出慢会导致定期logfileswitch(checkpointnocomplete)检查点无法完成的前台等待。这个physicalwrite包含了physicalwritesdirect+physicalwritesfromcacheUserCalls单位次数，用户调用数，moredetailsfrominternalParses解析次数，包括软解析+硬解析，软解析优化得不好，则夸张地说几乎等于每秒SQL执行次数。即执行解析比1:1，而我们希望的是解析一次到处运行哦！HardParses万恶之源．　CursorpinsonX，librarycache:mutexX，latch:rowcacheobjects/sharedpool……………..。硬解析最好少于每秒20次W/AMBprocessed单位MBW/Aworkareaworkarea中处理的数据数量结合In-memorySort%，sorts(disk)PGAAggr一起看Logons登陆次数，logonstorm登陆风暴，结合AUDIT审计数据一起看。短连接的附带效应是游标缓存无用Executes执行次数，反应执行频率Rollback回滚次数，反应回滚频率，但是这个指标不太精确，参考而已，别太当真Transactions每秒事务数，是数据库层的TPS，可以看做压力测试或比对性能时的一个指标，孤立看无意义%BlockschangedperRead每次逻辑读导致数据块变化的比率；如果’redosize’,‘blockchanges’‘pctofblockschangedperread’三个指标都很高，则说明系统正执行大量insert/update/delete;pctofblockschangedperread=(blockchanges)/(logicalreads)RecursiveCall%递归调用的比率;RecursiveCall%=(recursivecalls)/(usercalls)Rollbackpertransaction%事务回滚比率。Rollbackpertransaction%=(rollback)/(transactions)RowsperSort平均每次排序涉及到的行数;RowsperSort=(sorts(rows))/(sorts(disk)+sorts(memory))注意这些LoadProfile负载指标在本环节提供了2个维度persecond和pertransaction。perSecond:主要是把快照内的delta值除以快站时间的秒数，例如在A快照中V$SYSSTAT视图反应tablescans(longtables)这个指标是100，在B快照中V$SYSSTAT视图反应tablescans(longtables)这个指标是3700,而A快照和B快照之间间隔了一个小时3600秒，则对于tablescans(longtables)persecond就是(3700-100)/3600=1。pertSecond是我们审视数据的主要维度，任何性能数据脱离了时间模型则毫无意义。在statspack/AWR出现之前的调优洪荒时代，有很多DBA依赖V$SYSSTAT等视图中的累计统计信息来调优，以当前的调优眼光来看，那无异于刀耕火种。pertransaction:基于事务的维度，与persecond相比是把除数从时间的秒数改为了该段时间内的事务数。这个维度的很大用户是用来识别应用特性的变化，若2个AWR性能报告中该维度指标出现了大幅变化，例如redosize从本来pertransaction1k变化为10kpertransaction，则说明SQL业务逻辑肯定发生了某些变化。注意AWR中的这些指标并不仅仅用来孤立地了解Oracle数据库负载情况，实施调优工作。对于故障诊断例如HANG、Crash等，完全可以通过对比问题时段的性能报告和常规时间来对比，通过各项指标的对比往往可以找出病灶所在。SELECTVALUEFROMDBA_HIST_SYSSTATWHERES