OracleAWR报告指标全解析概要.docx
《OracleAWR报告指标全解析概要.docx》由会员分享，可在线阅读，更多相关《OracleAWR报告指标全解析概要.docx（136页珍藏版）》请在冰点文库上搜索。
OracleAWR报告指标全解析概要
OracleAWR报告指标全解析 2014-10-1614:
48:
04
分类：
Oracle
【性能调优】OracleAWR报告指标全解析
2013/08/31 BY MACLEANLIU 26条评论
【性能调优】OracleAWR报告指标全解析
开Oracle调优鹰眼，深入理解AWR性能报告：
开Oracle调优鹰眼，深入理解AWR性能报告第二讲：
文章出处：
（转载这篇文章主要是想跟大家分享一下，写的不错哦，感兴趣的可以买本书看看）
有同学在看过《Oracle调优鹰眼，深入理解AWR性能报告》的教学视频后急切期待第三讲，但实际是第三讲需要结合大量的原理知识才能充分理解例如Latchactivity、Undo、DynamicResourceMaster均需要理解其原理才能充分理解。
所以这些AWR的环节将在Maclean今后的系列调优讲座中介绍。
对于《Oracle调优鹰眼系列》则会增加本附录，作为对全部OracleAWR指标的介绍，本附录对于原理理解方面的内容将不多，而更侧重于指标含义的介绍，是对AWR鹰眼讲座的工具文档。
如果你觉得本AWR解析中的哪些指标仍理解不透彻或者讲的不清楚的，可以在本页中留言，谢谢大家的支持。
HawkEyes看AWR的鹰眼=基础理论夯实+看过500份以上AWR
啥是AWR?
=====================================================================================================
AWR（AutomaticWorkloadRepository）
一堆历史性能数据，放在SYSAUX表空间上，AWR和SYSAUX都是10g出现的，是Oracle调优的关键特性；大约1999年左右开始开发，已经有15年历史
默认快照间隔1小时，10g保存7天、11g保存8天;可以通过DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS修改
DBA_HIST_WR_CONTROL
AWR程序核心是dbms_workload_repository包
@?
/rdbms/admin/awrrpt 本实例
@?
/rdbms/admin/awrrpti RAC中选择实例号
谁维护AWR?
主要是MMON（ManageabilityMonitorProcess）和它的小工进程（m00x）
MMON的功能包括:
1.启动slave进程m00x去做AWR快照
2.当某个度量阀值被超过时发出alert告警
3.为最近改变过的SQL对象捕获指标信息
AWR小技巧
手动执行一个快照：
Execdbms_workload_repository.create_snapshot;（这个要背出来哦，用的时候去翻手册，丢脸哦J!
）
创建一个AWR基线
ExecDBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE（start_snap_id，end_snap_id,baseline_name）;
@?
/rdbms/admin/awrddrpt AWR比对报告
@?
/rdbms/admin/awrgrpt RAC全局AWR
自动生成AWRHTML报告：
http:
//www.oracle-
1、报告总结
WORKLOADREPOSITORYreportfor
DBNameDBIdInstanceInstNumStartupTimeReleaseRAC
------------------------------------------------------------------------
MAC2629627371122-Jan-1316:
4911.2.0.3.0YES
HostNamePlatformCPUsCoresSocketsMemory（GB）
--------------------------------------------------------------------------
MAC10AIX-BasedSystems（64-bit）12832320.00
SnapIdSnapTimeSessionsCurs/Sess
---------------------------------------------
BeginSnap:
585323-Jan-1315:
00:
563,5201.8
EndSnap:
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、和其他一系列非空闲等待时间，别忘了cpuonqueuetime
DBTIME不等于响应时间，DBTIME高了未必响应慢，DBTIME低了未必响应快
DBTime描绘了数据库总体负载，但要和elapsedtime逝去时间结合其他来。
AverageActiveSessionAAS=DBtime/ElapsedTime
DBTime=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=120
AAS=120/60=2 正好等于OSload2。
如果有3个session都100%仅消耗CPU，那么总有一个要waitonqueue
DBCPU=2*60mins ，waitonCPUqueue=60mins
AAS=（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:
8K
SharedPoolSize:
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-2 LoadProfile
LoadProfilePerSecondPerTransactionPerExecPerCall
~~~~~~~~~~~~--------------------------------------------------
DBTime（s）:
256.60.20.070.03
DBCPU（s）:
3.70.00.000.00
Redosize:
1,020,943.0826.5
Logicalreads:
196,888.0159.4
Blockchanges:
6,339.45.1
Physicalreads:
5,076.74.1
Physicalwrites:
379.20.3
Usercalls:
10,157.48.2
Parses:
204.00.2
Hardparses:
0.90.0
W/AMBprocessed:
5.00.0
Logons:
1.70.0
Executes:
3,936.63.2
Rollbacks:
1,126.30.9
Transactions:
1,235.3
%BlockschangedperRead:
53.49RecursiveCall%:
98.04
Rollbackpertransaction%:
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
单位次数*块数，描绘数据变化频率
PhysicalRead
单位次数*块数，如上例5076*8k=39MB/s，物理读消耗IO读，体现在IOPS和吞吐量等不同纬度上；但减少物理读可能意味着消耗更多CPU。
好的存储每秒物理读能力达到几GB，例如Exadata。
这个physicalread包含了physicalreadscache和physicalreadsdirect
Physicalwrites
单位 次数*块数，主要是DBWR写datafile，也有directpathwrite。
dbwr长期写出慢会导致定期logfileswitch（checkpointnocomplete）检查点无法完成的前台等待。
这个physicalwrite包含了physicalwritesdirect+physicalwritesfromcache
UserCalls
单位次数，用户调用数，moredetailsfrominternal
Parses
解析次数，包括软解析+硬解析，软解析优化得不好，则夸张地说几乎等于每秒SQL执行次数。
即执行解析比1:
1，而我们希望的是解析一次到处运行哦！
HardParses
万恶之源． CursorpinsonX，librarycache:
mutexX，latch:
rowcacheobjects/sharedpool……………..。
硬解析最好少于每秒20次
W/AMBprocessed
单位MB W/Aworkarea workarea中处理的数据数量
结合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从本来pertransaction 1k变化为 10kpertransaction，则说明SQL业务逻辑肯定发生了某些变化。
注意AWR中的这些指标并不仅仅用来孤立地了解Oracle数据库负载情况，实施调优工作。
对于故障诊断例如HANG、Crash等，完全可以通过对比问题时段的性能报告和常规时间来对比，通过各项指标的对比往往可以找出病灶所在。
SELECTVALUEFROMDBA_HIST_SYSSTATWHERESNAP_ID=:
B4ANDDBID=:
B3ANDINSTANCE_NUMBER=:
B2ANDSTAT_NAME in（ "dbblockchanges","usercalls","userrollbacks","usercommits",redosize","physicalreadsdirect","physicalwrites","parsecount（hard）","parsecount（total）","sessionlogicalreads","recursivecalls","redologspacerequests","redoentries","sorts（memory）","sorts（disk）","sorts（rows）","logonscumulative","parsetimecpu","parsetimeelapsed","executecount","logonscurrent","openedcursorscurrent","DBWRfusionwrites","gcsmessagessent","gesmessagessent","globalenqueuegetssync","globalenqueuegettime","gccrblocksreceived","gccrblockreceivetime","gccurrentblocksreceived","gccurrentblockreceivetime","gccrblocksserved","gccrblockbuildtime","gccrblockflushtime","gccrblocksendtime","gccurrentblocksserved","gccurrentblockpintime","gccurrentblockflushtime","gccurrentblocksendtime","physicalreads","physicalreadsdirect（lob）",
SELECTTOTAL_WAITSFROMDBA_HIST_SYSTEM_EVENTWHERESNAP_ID=:
B4ANDDBID=:
B3ANDINSTANCE_NUMBER=:
B2ANDEVENT_NAMEin（"gcbufferbusy","bufferbusywaits"
SELECTVALUEFROMDBA_HIST_SYS_TIME_MODELWHEREDBID=:
B4ANDSNAP_ID=:
B3ANDINSTANCE_NUMBER=:
B2ANDSTAT_NAME in （"DBCPU","sqlexecuteelapsedtime","DBtime"
SELECTVALUEFROMDBA_HIST_PARAMETERWHERESNAP_ID=:
B4ANDDBID=:
B3ANDINSTANCE_NUMBER=:
B2ANDPARAMETER_NAME in（"__db_cache_size","__shared_pool_size","sga_target","pga_aggregate_target","undo_management","db_block_size","log_buffer","timed_statistics","statistics_level"
SELECTBYTESFROMDBA_HIST_SGASTATWHERESNAP_ID=:
B4ANDDBID=:
B3ANDINSTANCE_NUMBER=:
B2ANDPOOLIN（'sharedpool','allpools'）ANDNAME in（"freememory",
SELECTBYTESFROMDBA_HIST_SGASTATWHERESNAP_ID=:
B4ANDDBID=:
B3ANDINSTANCE_NUMBER=:
B2ANDNAME=:
B1ANDPOOLISNULL
SELECT（E.BYTES_PROCESSED-B.BYTES_PROCESSED）FROMDBA_HIST_PGA_TARGET_ADVICEB,DBA_HIST_PGA_TARGET_ADVICEEWHEREB.DBID=:
B4ANDB.SNAP_ID=:
B3ANDB.INSTANCE_NUM
BER=:
B2ANDB.ADVICE_STATUS='ON'ANDE.DBID=B.DBIDANDE.SNAP_ID=:
B1ANDE.INSTANCE_NUMBER=B.INSTANCE_NUMBERANDE.PGA_TARGET_FACTOR=1ANDB.PGA_TARGET_FACT
OR=1ANDE.ADVICE_STATUS='ON'
SELECTSUM（E.TOTAL_WAITS-NVL（B.TOTAL_WAITS,0））FROMDBA_HIST_SYSTEM_EVENTB,DBA_HIST_SYSTEM_EVENTEWHEREB.SNAP_ID（+）=:
B4ANDE.SNAP_ID
升级会员 