=====================================================================================================
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/awrrptiRAC中选择实例号
主要是MMON(ManageabilityMonitorProcess)和它的小工进程(m00x)
MMON的功能包括:1.启动slave进程m00x去做AWR快照2.当某个度量阀值被超过时发出alert告警3.为最近改变过的SQL对象捕获指标信息
1.手动执行一个快照：
Execdbms_workload_repository.create_snapshot;
2.创建一个AWR基线
ExecDBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id，end_snap_id,baseline_name);
3.AWR比对报告
@/rdbms/admin/awrddrpt
4.RAC全局AWR
@/rdbms/admin/awrgrpt
5.自动生成AWRHTML报告：
AverageActiveSession：AAS=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=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+………..阿猫阿狗
内存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target)
Buffercache和sharedpoolsize的begin/end值在ASMM、AMM和11gR2MSMM下可是会动的哦！
这里说sharedpool一直收缩，则在shrink过程中一些rowcache对象被lock住可能导致前台rowcachelock等解析等待，最好别让sharedpoolshrink。如果这里sharedpool一直在grow，那说明sharedpool原有大小不足以满足需求(可能是大量硬解析)，结合下文的解析信息和SGAbreakdown来一起诊断问题。
注意这些LoadProfile负载指标在本环节提供了2个维度persecond和pertransaction。
在statspack/AWR出现之前的调优洪荒时代，有很多DBA依赖V$SYSSTAT等视图中的累计统计信息来调优，以当前的调优眼光来看，那无异于刀耕火种。
上述所有指标的目标均为100%，即越大越好，在少数bug情况下可能超过100%或者为负值。
1、BufferNowait%session申请一个buffer(兼容模式)不等待的次数比例。需要访问buffer时立即可以访问的比率，不兼容的情况在9i中是bufferbusywaits，从10g以后bufferbusywaits分离为bufferbusywait和readbyothersession2个等待事件:
9i中waitstat的总次数基本等于bufferbusywaits等待事件的次数SQL>selectsum(TOTAL_WAITS)fromv$system_eventwhereevent='bufferbusywaits';SUM(TOTAL_WAITS)—————-33070394SQL>selectsum(count)fromv$waitstat;SUM(COUNT)———-3306933510gwaitstat的总次数基本等于bufferbusywaits和readbyothersession等待的次数总和SQL>selectsum(TOTAL_WAITS)fromv$system_eventwhereevent='bufferbusywaits'orevent='readbyothersession';SUM(TOTAL_WAITS)—————-60675815SQL>selectsum(count)fromv$waitstat;SUM(COUNT)———-60423739BufferNowait%的计算公式是sum(v$waitstat.wait_count)/(v$sysstatstatisticsessionlogicalreads)，例如在AWR中：
BufferNowait=(40,769,800–(24543+743+1116+35))/(40,769,800)=0.99935=99.94%
SELECTSUM(WAIT_COUNT)FROMDBA_HIST_WAITSTATWHERESNAP_ID=:B3ANDDBID=:B2ANDINSTANCE_NUMBER=:B1
2、bufferHIT%:经典的经典，高速缓存命中率，反应物理读和缓存命中间的纠结，但这个指标即便99%也不能说明物理读等待少了
不合理的db_cache_size，或者是SGA自动管理ASMM/Memory自动管理AMM下都可能因为db_cache_size过小引起大量的dbfilesequential/scatteredread等待事件；maclean曾经遇到过因为大量硬解析导致ASMM下sharedpool共享池大幅度膨胀，而dbcache相应缩小shrink的例子，最终dbcache收缩到只有几百兆，本来没有的物理读等待事件都大幅涌现出来。
bufferHIT%在不同版本有多个计算公式：
在9i中
BufferHitRatio=1–((physicalreads–physicalreadsdirect–physicalreadsdirect(lob))/(dbblockgets+consistentgets–physicalreadsdirect–physicalreadsdirect(lob))
在10g以后：
BufferHitRatio=1–((‘physicalreadscache’)/(‘consistentgetsfromcache’+‘dbblockgetsfromcache’)
注意：但是实际AWR中似乎还是按照9i中的算法，虽然算法的区别对最后算得的比率影响不大。
dbblockgets、consistentgets以及sessionlogicalreads的关系如下：
dbblockgets＝dbblockgetsdirect＋dbblockgetsfromcache
consistentgets＝consistentgetsfromcache＋consistentgetsdirect
consistentgetsfromcache＝consistentgets–examination+else
consistentgets–examination==>指的是不需要pinbuffer直接可以执行consistentget的次数，常用于索引，只需要一次latchget
sessionlogicalreads=dbblockgets+consistentgets
其中physicalreads、physicalreadscache、physicalreadsdirect、physicalreadsdirect(lob)几者的关系为：
physicalreads=physicalreadscache+physicalreadsdirect
这个公式其实说明了物理读有2种：
physicalreadsdirect=physicalreadsdirect(lob)+physicalreadsdirecttemporarytablespace+physicalreadsdirect(普通)
这个公式也说明了直接路径读分成三个部分：
physicalwritesdirect=physicalwritesdirect(lob)+physicalwritesdirecttemporarytablespace
DBWRcheckpointbufferswritten=DBWRthreadcheckpointbufferswritten+DBWRtablespacecheckpointbufferswritten+DBWRPQtablespacecheckpointbufferswritten+….
此外保证SQL语句绑定变量和游标可以共享也是很重要的因素。
SELECTSUM(PINS),SUM(PINHITS)FROMDBA_HIST_LIBRARYCACHEWHERESNAP_ID=:B3ANDDBID=:B2ANDINSTANCE_NUMBER=:B1
在oracle中解析往往是执行的先提工作，但是通过游标共享可以解析一次执行多次，执行解析可能分成多种场景：
通俗地说softparse%反映了软解析率，而软解析在oracle中仍是较昂贵的操作，我们希望的是解析1次执行N次，如果每次执行均需要软解析，那么虽然softparse%=100%但是parsetime仍可能是消耗DBTIME的大头。
ExecutetoParse反映了执行解析比，ExecutetoParse和softparse%都很低那么说明确实没有绑定变量，而如果softparse%接近99%而ExecutetoParse不足90%则说明没有执行解析比低，需要通过静态SQL、动态绑定、session_cached_cursor、opencursors等技术减少软解析。
LatchName----------------------------------------GetRequestsMissesSleepsSpinGetsSleep1Sleep2Sleep3----------------------------------------------------------------------sharedpool9,988,63736423341000librarycache6,753,4681526146000MemoryManagementLatch369110000qmntaskqueuelatch24110000LatchHit%:=(1–(Sum(misses)/Sum(gets)))
关于Latch的更多信息内容可以参考AWR后面的专栏LatchStatistics，注意对于一个并发设计良好的OLTP应用来说，Latch、Enqueue等并发控制不应当成为系统的主要瓶颈，同时对于这些并发争用而言堆积硬件CPU和内存很难有效改善性能。
SELECTSUM(GETS),SUM(MISSES)FROMDBA_HIST_LATCHWHERESNAP_ID=:B3ANDDBID=:B2ANDINSTANCE_NUMBER=:B1
该环节提供一个大致的SQL重用及sharedpool内存使用的评估。应用是否共享SQL有多少内存是给只运行一次的SQL占掉的，对比共享SQL呢？
如果该环节中%SQLwithexecutions>1的比例小于%90，考虑用下面链接的SQL去抓硬编码的非绑定变量SQL语句。
MemoryUsage%:(sharedpool的实时大小-sharedpoolfreememory)/sharedpool的实时大小，代表sharedpool的空间使用率，虽然有使用率但没有标明碎片程度
==》上面2个指标也可以用来大致了解sharedpool中的内存碎片程序，因为SINGLE_USE_SQL单次执行的SQL多的话，那么显然可能有较多的共享池内存碎片
SQL复用率低的原因一般来说就是硬绑定变量(hardCoding)未合理使用绑定变量(bindvariable)，对于这种现象短期无法修改代表使用绑定变量的可以ALTERSYSTEMSETCURSOR_SHARING=FORCE;来绕过问题，对于长期来看还是要修改代码绑定变量。Oracle从11g开始宣称今后将废弃CURSOR_SHARING的SIMILAR选项，同时SIMILAR选项本身也造成了很多问题，所以一律不推荐用CURSOR_SHARING=SIMILAR。
基于WaitInterface的调优是目前的主流！每个指标都重要！
基于命中比例的调优，好比是统计局的报告，张财主家财产100万，李木匠家财产1万，平均财产50.5万。
基于等待事件的调优，好比马路上100辆汽车的行驶记录表，上车用了几分钟，红灯等了几分钟，拥堵塞了几分钟。。。
丰富的等待事件以足够的细节来描绘系统运行的性能瓶颈，这是Mysql梦寐以求的东西……
Waits:该等待事件发生的次数，对于DBCPU此项不可用
%TotalCallTime，该等待事件占总的calltime的比率
totalcalltime=totalCPUtime+totalwaittimefornon-idleevents
%TotalCallTime=timeforeachtimedevent/totalcalltime
WaitClass:等待类型：Concurrency,SystemI/O,UserI/O,Administrative,Other,Configuration,Scheduler,Cluster,Application,Idle,Network,Commit
几种常见的等待事件
=========================>
enq:XX队列锁等待，视乎不同的队列锁有不同的情况：
freebufferwaits：是由于无法找到可用的buffercache空闲区域，需要等待DBWR写入完成引起
writecompletewaits:一般此类等待事件是由于DBWR将脏数据写入数据文件，其他进程如果需要修改buffercache会引起此等待事件，一般是I/O性能问题或者是DBWR工作负荷过量引起
Waittime1Seconds.
controlfileparallelwrite：频繁的更新控制文件会造成大量此类等待事件，如日志频繁切换，检查点经常发生，nologging引起频繁的数据文件更改，I/O系统性能缓慢。
TimeModelStatisticsDB/Inst:ITSCMP/itscmp2Snaps:70719-70723->Totaltimeindatabaseuser-calls(DBTime):883542.2s->Statisticsincludingtheword"background"measurebackgroundprocesstime,andsodonotcontributetotheDBtimestatistic->Orderedby%orDBtimedesc,StatisticnameStatisticNameTime(s)%ofDBTime------------------------------------------------------------------------sqlexecuteelapsedtime805,159.791.1sequenceloadelapsedtime41,159.24.7DBCPU20,649.12.3parsetimeelapsed1,112.8.1hardparseelapsedtime995.2.1hardparse(sharingcriteria)elapsedtime237.3.0hardparse(bindmismatch)elapsedtime227.6.0connectionmanagementcallelapsedtime29.7.0PL/SQLexecutionelapsedtime9.2.0PL/SQLcompilationelapsedtime6.6.0failedparseelapsedtime2.0.0repeatedbindelapsedtime0.4.0DBtime883,542.2backgroundelapsedtime25,439.0backgroundcputime1,980.9-------------------------------------------------------------
1)backgroundelapsedtime2)backgroundcputime3)RMANcputime(backup/restore)1)DBtime2)DBCPU2)connectionmanagementcallelapsedtime2)sequenceloadelapsedtime2)sqlexecuteelapsedtime2)parsetimeelapsed3)hardparseelapsedtime4)hardparse(sharingcriteria)elapsedtime5)hardparse(bindmismatch)elapsedtime3)failedparseelapsedtime4)failedparse(outofsharedmemory)elapsedtime2)PL/SQLexecutionelapsedtime2)inboundPL/SQLrpcelapsedtime2)PL/SQLcompilationelapsedtime2)Javaexecutionelapsedtime2)repeatedbindelapsedtime
ForegroundWaitClass->s-second,ms-millisecond-1000thofasecond->orderedbywaittimedesc,waitsdesc->%Timeouts:valueof0indicatesvaluewas<.5%.Valueofnullistruly0->CapturedTimeaccountsfor102.7%ofTotalDBtime883,542.21(s)->TotalFGWaitTime:886,957.73(s)DBCPUtime:20,649.06(s)Avg%TimeTotalWaitwaitWaitClassWaits-outsTime(s)(ms)%DBtime--------------------------------------------------------------------------Cluster9,825,8841525,1345359.4Concurrency688,3750113,78216512.9UserI/O34,405,042076,69528.7Commit172,193062,7763657.1Application11,422057,76050576.5Configuration19,418148,88925185.5DBCPU20,6492.3Other1,757,8969492410.1SystemI/O30,1650598200.1Network171,955,673040000.0Administrative210001010.0-------------------------------------------------------------selectdistinctwait_classfromv$event_name;WAIT_CLASS----------------------------------------------------------------ConcurrencyUserI/OSystemI/OAdministrativeOtherConfigurationSchedulerClusterApplicationQueueingIdleNetworkCommit
Other类型，遇到该类型等待事件的话常见的原因是OracleBug或者网络、I/O存在问题，一般推荐联系Maclean。
Concurrency类型并行争用类型的等待事件，典型的如latch:sharedpool、latch:librarycache、rowcachelock、librarycachepin/lock
Cluster类型为RealApplicationClusterRAC环境中的等待事件，需要注意的是如果启用了RACoption，那么即使你的集群中只启动了一个实例，那么该实例也可能遇到Cluster类型的等待事件,例如gcbufferbusy
SystemI/O主要是后台进程维护数据库所产生的I/O，例如controlfileparallelwrite、logfileparallelwrite、dbfileparallelwrite。
UserI/O主要是前台进程做了一些I/O操作，并不是说后台进程不会有这些等待事件。典型的如dbfilesequential/scatteredread、directpathread
Configuration由于配置引起的等待事件，例如日志切换的logfileswitchcompletion(日志文件大小/数目不够)，sequence的enq:SQ–contention(Sequence使用nocache)；Oracle认为它们是由于配置不当引起的，但实际未必真是这样的配置引起的。
Application应用造成的等待事件，例如enq:TM–contention和enq:TX–rowlockcontention；Oracle认为这是由于应用设计不当造成的等待事件，但实际这些Applicationclass等待可能受到Concurrency、Cluster、SystemI/O、UserI/O等多种类型等待的影响，例如本来commit只要1ms，则某一行数据仅被锁定1ms，但由于commit变慢从而释放行锁变慢，引发大量的enq:TX–rowlockcontention等待事件。
Commit仅logfilesync，logfilesync的影响十分广泛，值得我们深入讨论。
Network:网络类型的等待事件例如SQL*Netmoredatatoclient、SQL*Netmoredatatodblink
Idle空闲等待事件，最为常见的是rdbmsipcmessage(等待实例内部的ipc通信才干活，即别人告知我有活干，我才干，否则我休息==》Idle)，SQL*Netmessagefromclient(等待SQL*NET传来信息，否则目前没事干)
ForegroundWaitEventsSnaps:70719-70723->s-second,ms-millisecond-1000thofasecond->OnlyeventswithTotalWaitTime(s)>=.001areshown->orderedbywaittimedesc,waitsdesc(idleeventslast)->%Timeouts:valueof0indicatesvaluewas<.5%.Valueofnullistruly0Avg%TimeTotalWaitwaitWaits%DBEventWaits-outsTime(s)(ms)/txntime--------------------------------------------------------------------------gcbufferbusyacquire3,274,3523303,0889313.334.3gcbufferbusyrelease387,6732128,1143301.614.5enq:TX-indexcontention193,918097,3755020.811.0cellsingleblockphysical30,738,730063,6062124.87.2logfilesync172,193062,7763650.77.1gccurrentblockbusy146,154053,0273630.66.0enq:TM-contention1,060047,228445550.05.3enq:SQ-contention17,431035,68320470.14.0gccrblockbusy105,204033,7463210.43.8bufferbusywaits279,721012,646451.11.4enq:HW-contention1,201312,192101510.01.4enq:TX-rowlockcontent9,231010,48211350.01.2cellmultiblockphysicalr247,90306,547261.0.7
Event等待事件名字
Waits/Txn:该等待事件的等待次数和事务比
BackgroundWaitEventsSnaps:70719-70723->orderedbywaittimedesc,waitsdesc(idleeventslast)->OnlyeventswithTotalWaitTime(s)>=.001areshown->%Timeouts:valueof0indicatesvaluewas<.5%.Valueofnullistruly0Avg%TimeTotalWaitwaitWaits%bgEventWaits-outsTime(s)(ms)/txntime--------------------------------------------------------------------------dbfileparallelwrite90,97907,831860.430.8gcslogflushsync4,756,07664,714119.318.5enq:CF-contention2,123404,03819020.015.9controlfilesequentialre90,22702,380260.49.4logfileparallelwrite108,38301,723160.46.8controlfileparallelwrit4,81209882050.03.9DiskfileoperationsI/O26,2160731280.12.9flashbacklogfilewrite9,8700720730.02.8LNSwaitonSENDREQ202,747060030.82.4ASMfilemetadataoperatio15,8010344220.11.4cellsingleblockphysical39,283034190.21.3LGWR-LNSwaitonchannel183,4431820310.7.8gccurrentblockbusy122013210820.0.5gcbufferbusyrelease601212721130.0.5ParameterFileI/O59201161950.0.5logfilesequentialread1,8040104580.0.4
OperatingSystemStatisticsSnaps:70719-70723TIMEstatisticvaluesarediffed.Allothersdisplayactualvalues.EndValueisdisplayedifdifferent->orderedbystatistictype(CPUUse,VirtualMemory,HardwareConfig),NameStatisticValueEndValue---------------------------------------------------------------BUSY_TIME2,894,855IDLE_TIME5,568,240IOWAIT_TIME18,973SYS_TIME602,532USER_TIME2,090,082LOAD813VM_IN_BYTES0VM_OUT_BYTES0PHYSICAL_MEMORY_BYTES101,221,343,232NUM_CPUS24NUM_CPU_CORES12NUM_CPU_SOCKETS2GLOBAL_RECEIVE_SIZE_MAX4,194,304GLOBAL_SEND_SIZE_MAX2,097,152TCP_RECEIVE_SIZE_DEFAULT87,380TCP_RECEIVE_SIZE_MAX4,194,304TCP_RECEIVE_SIZE_MIN4,096TCP_SEND_SIZE_DEFAULT16,384TCP_SEND_SIZE_MAX4,194,304TCP_SEND_SIZE_MIN4,096-------------------------------------------------------------
OperatingSystemStatistics操作系统统计信息
ServiceStatisticsSnaps:70719-70723->orderedbyDBTimePhysicalLogicalServiceNameDBTime(s)DBCPU(s)Reads(K)Reads(K)----------------------------------------------------------------------------itms-contentmasterdb-prod897,09920,61835,6681,958,580SYS$USERS4,3121895,95713,333itmscmp1,94112114,94918,187itscmp33120114218itscmp_dgmgrl121100SYS$BACKGROUND0014230,022ITSCMP1_PR0000its-reference-prod0000itscmpXDB0000
PhysicalReads:本服务名所消耗的物理读
LogicalReads:本服务所消耗的逻辑读
ServiceWaitClassStatsSnaps:70719-70723->WaitClassinfoforservicesintheServiceStatisticssection.->TotalWaitsandTimeWaiteddisplayedforthefollowingwaitclasses:UserI/O,Concurrency,Administrative,Network->TimeWaited(WtTime)insecondsServiceName----------------------------------------------------------------UserI/OUserI/OConcurcyConcurcyAdminAdminNetworkNetworkTotalWtsWtTimeTotalWtsWtTimeTotalWtsWtTimeTotalWtsWtTime------------------------------------------------------------------------itms-contentmasterdb-prod3332167071443678373113759001.718E+08127SYS$USERS173233365667383020726743itmscmp6767731319183100022160itscmp2195772361093000181120itscmp_dgmgrl340800090SYS$BACKGROUND7194013003206775600442252872-------------------------------------------------------------
HostCPU(CPUs:24Cores:12Sockets:2)~~~~~~~~LoadAverageBeginEnd%User%System%WIO%Idle------------------------------------------------------8.4112.8424.77.10.265.8
“LoadAverage”begin/end值代表每个CPU的大致运行队列大小。上例中快照开始到结束，平均CPU负载增加了；与《2-5OperatingSystemStatistics》中的LOAD相呼应。
%User+%System=>总的CPU使用率，在这里是31.8%
ElapsedTime*NUM_CPUS*CPUutilization=60.23(mins)*24*31.8%=459.67536mins=BusyTime
InstanceCPU~~~~~~~~~~~~%oftotalCPUforInstance:26.7%ofbusyCPUforInstance:78.2%DBtimewaitingforCPU-ResourceMgr:0.0%TotalCPU,该实例所使用的CPU占总CPU的比例%oftotalCPUforInstance
%BusyCPU，该实例所使用的Cpu占总的被使用CPU的比例%ofbusyCPUforInstance
例如共4个逻辑CPU，其中3个被完全使用，3个中的1个完全被该实例使用，则%TotalCPU==25%，而%BusyCPU=1/3=33%
当CPU高时一般看%BusyCPU可以确定CPU到底是否是本实例消耗的，还是主机上其他程序
%ofbusyCPUforInstance=（DBCPU+backgroundcputime)/(BUSY_TIME/100)=(20,649.1+1,980.9)/(2,894,855/100)=78.17%
%ofTotalCPUforInstance=(DBCPU+backgroundcputime)/(BUSY_TIME+IDLE_TIME/100)=(20,649.1+1,980.9)/((2,894,855+5,568,240)/100)=26.73%
%DBtimewaitingforCPU(ResourceManager)=(RSRC_MGR_CPU_WAIT_TIME/100)/DBTIME
SQLorderedbyElapsedTimeSnaps:70719-70723->ResourcesreportedforPL/SQLcodeincludestheresourcesusedbyallSQLstatementscalledbythecode.->%TotalDBTimeistheElapsedTimeoftheSQLstatementdividedintotheTotalDatabaseTimemultipliedby100->%Total-ElapsedTimeasapercentageofTotalDBtime->%CPU-CPUTimeasapercentageofElapsedTime->%IO-UserI/OTimeasapercentageofElapsedTime->CapturedSQLaccountfor53.9%ofTotalDBTime(s):883,542->CapturedPL/SQLaccountfor0.5%ofTotalDBTime(s):883,542ElapsedElapsedTimeTime(s)ExecutionsperExec(s)%Total%CPU%IOSQLId--------------------------------------------------------------------------181,411.338,8484.6720.5.0.1g0yc9szpuu068注意对于PL/SQL，SQLStatistics不仅会体现该PL/SQL的执行情况，还会包括该PL/SQL包含的SQL语句的情况。如上例一个TOPPL/SQL执行了448s，而这448s中绝大多数是这个PL/SQL下的一个SQL执行500次耗费的。
则该TOPPL/SQL和TOPSQL都上榜，一个执行一次耗时448s，一个执行500次耗时448s。如此情况则ElapsedTime加起来可能超过100%的ElapsedTime，这是正常的。
对于鹤立鸡群的SQL很有必要一探究竟，跑个@/rdbms/admin/awrsqrpt看看吧！
对于维护操作，例如加载或清除数据，大的跑批次、报表而言ElapsedTimeperExec(s)高一些是正常的。
SQLId:通过计算SQL文本获得的SQL_ID，不同的SQL文本必然有不同的SQL_ID，对于10g~11g而言只要SQL文本不变那么在数据库之间该SQL对应的SQL_ID应当不不变的，12c中修改了SQL_ID的计算方法
CapturedSQLaccountfor53.9%ofTotalDBTime(s)对于不绑定变量的应用来说TopSQL有可能失准，所以要参考本项
SQLorderedbyCPUTimeSnaps:70719-70723->ResourcesreportedforPL/SQLcodeincludestheresourcesusedbyallSQLstatementscalledbythecode.->%Total-CPUTimeasapercentageofTotalDBCPU->%CPU-CPUTimeasapercentageofElapsedTime->%IO-UserI/OTimeasapercentageofElapsedTime->CapturedSQLaccountfor34.9%ofTotalCPUTime(s):20,649->CapturedPL/SQLaccountfor0.5%ofTotalCPUTime(s):20,649CPUCPUperElapsedTime(s)ExecutionsExec(s)%TotalTime(s)%CPU%IOSQLId-------------------------------------------------------------------------1,545.01,864,4240.007.54,687.833.065.78g6a701j83c8qModule:MZIndexerSELECTt0.BOOLEAN_VALUE,t0.CLASS_CODE,t0.CREATED,t0.END_DATE,t0.PRODUCT_ATTRIBUTE_ID,t0.LAST_MODIFIED,t0.OVERRIDE_FLAG,t0.PRICE,t0.PRODUCT_ATTRIBUTE_TYPE_ID,t0.PRODUCT_ID,t0.PRODUCT_PUB_RELEASE_TYPE_ID,t0.PRODUCT_VOD_TYPE_ID,t0.SAP_PRODUCT_ID,t0.START_DATE,t0.STRING_VALUEFROMmz_product_attributet0WHER
SQLorderedbyGetsDB/Inst:ITSCMP/itscmp2Snaps:70719-70723->ResourcesreportedforPL/SQLcodeincludestheresourcesusedbyallSQLstatementscalledbythecode.->%Total-BufferGetsasapercentageofTotalBufferGets->%CPU-CPUTimeasapercentageofElapsedTime->%IO-UserI/OTimeasapercentageofElapsedTime->TotalBufferGets:2,021,476,421->CapturedSQLaccountfor68.2%ofTotalBufferGetsElapsedGetsExecutionsperExec%TotalTime(s)%CPU%IOSQLId-------------------------------------------------------------------------4.61155E+081,864,424247.322.84,687.833.065.78g6a701j83c
注意buffergets逻辑读是消耗CPUTIME的重要源泉，但并不是说消耗CPUTIME的只有buffergets。大多数情况下SQLorderbyCPUTIME和SQLorderbybuffersgets2个部分的TOPSQL及其排列顺序都是一样的，此种情况说明消耗最多buffergets的就是消耗最多CPU的SQL，如果我们希望降低系统的CPU使用率，那么只需要调优SQL降低buffergets即可。
但也并不是100%的情况都是如此，CPUTIME的消耗者还包括函数运算、PL/SQL控制、Latch/Mutex的Spin等等，所以SQLorderbyCPUTIME和SQLorderbybuffersgets2个部分的TOPSQL完全不一样也是有可能的，需要因地制宜来探究到底是什么问题导致的HighCPU，进而裁度解决之道。
GetsperExec:该SQL平均单次的buffergets，对于事务型transaction操作而言一般该单次buffergets小于2000
%Total该SQL累计运行所消耗的buffergets占总的dbbuffergets的比率，(SQLbuffergets/DBtotalbuffergets)
SQLorderedbyReadsDB/Inst:ITSCMP/itscmp2Snaps:70719-70723->%Total-PhysicalReadsasapercentageofTotalDiskReads->%CPU-CPUTimeasapercentageofElapsedTime->%IO-UserI/OTimeasapercentageofElapsedTime->TotalDiskReads:56,839,035->CapturedSQLaccountfor34.0%ofTotalPhysicalReadsElapsedReadsExecutionsperExec%TotalTime(s)%CPU%IOSQLId-------------------------------------------------------------------------9,006,16319.0062E+0615.8720.95.980.94g36tmp70h185Physicalreads:该SQL累计运行所消耗的物理读
ReadsperExec:该SQL单次运行所消耗的物理读，(SQLPhysicalreads/Executions)，对于OLTPtransaction类型的操作而言单次一般不超过100
%Total:该SQL累计消耗的物理读占该时段总的物理读的比例，即(SQLphysicalread/TotalDBphysicalread)
SQLorderedbyExecutionsSnaps:70719-70723->%CPU-CPUTimeasapercentageofElapsedTime->%IO-UserI/OTimeasapercentageofElapsedTime->TotalExecutions:48,078,147->CapturedSQLaccountfor50.4%ofTotalElapsedExecutionsRowsProcessedRowsperExecTime(s)%CPU%IOSQLId--------------------------------------------------------------------------6,327,96311,249,6451.8590.547.852.71avv7759j8r
按照执行次数来排序的话，也是性能报告对比时一个重要的参考因素，因为如果TOPSQL的执行次数有明显的增长，那么性能问题的出现也是意料之中的事情了。当然执行次数最多的，未必便是对性能影响最大的TOPSQL
RowsperExec：SQL平均单次执行所处理的行数，这个指标在诊断一些数据问题造成的SQL性能问题时很有用
SQLorderedbyParseCallsSnaps:70719-70723->TotalParseCalls:2,160,124->CapturedSQLaccountfor58.3%ofTotal%TotalParseCallsExecutionsParsesSQLId----------------------------------------------496,475577,35722.98d07gaa3wntdff
ParseCalls:解析调用次数，与上文的LoadProfile中的Parse数一样包括软解析softparse和硬解析hardparse
%TotalParses:本SQL解析调用次数占该时段数据库总解析次数的比率，为(SQLParseCalls/TotalDBParseCalls)
SQLorderedbySharableMemorySnaps:70719-70723->OnlyStatementswithSharableMemorygreaterthan1048576aredisplayedSharableMem(b)Executions%TotalSQLId-------------------------------------------------8,468,359390.08au89sasqfb2ynModule:MZContentBridgeSELECTt0.ASPECT_RATIO,t0.CREATED,t0.FILE_EXTENSION,t0.HEIGHT,t0.VIDEO_FILE_DIMENSIONS_ID,t0.LAST_MODIFIED,t0.NAME,t0.WIDTHFROMMZ_VIDEO_FILE_DIMENSIONSt0WHERE(t0.HEIGHT=:1ANDt0.WIDTH=:2)
ShareableMem(b):SQL对象所占用的共享内存使用量
%Total:该SQL对象锁占共享内存占总的共享内存的比率
VersionCountOracle中的执行计划可以是多版本的，即对于同一个SQL语句有多个不同版本的执行计划，这些执行计划又称作子游标，而一个SQL语句的文本可以称作一个父游标。一个父游标对应多个子游标，产生不同子游标的原因是SQL在被执行时无法共享之前已经生成的子游标，原因是多种多样的，例如在本session中做了一个优化器参数的修改例如optimizer_index_cost_adj从100修改到99，则本session的优化环境optimizerenv将不同于之前的子游标生成环境，这样就需要生成一个新的子游标，例如：
SQL>createtableempasselect*fromscott.emp;Tablecreated.SQL>select*fromempwhereempno=1;norowsselectedSQL>select/*+MACLEAN*/*fromempwhereempno=1;norowsselectedSQL>selectSQL_ID,version_countfromV$SQLAREAWHERESQL_TEXTlike'%MACLEAN%'andSQL_TEXTnotlike'%like%';SQL_IDVERSION_COUNT--------------------------bxnnm7z1qmg261SQL>selectcount(*)fromv$SQLwhereSQL_ID='bxnnm7z1qmg26';COUNT(*)----------1SQL>altersessionsetoptimizer_index_cost_adj=99;Sessionaltered.SQL>select/*+MACLEAN*/*fromempwhereempno=1;norowsselectedSQL>selectSQL_ID,version_countfromV$SQLAREAWHERESQL_TEXTlike'%MACLEAN%'andSQL_TEXTnotlike'%like%';SQL_IDVERSION_COUNT--------------------------bxnnm7z1qmg262SQL>selectcount(*)fromv$SQLwhereSQL_ID='bxnnm7z1qmg26';COUNT(*)----------2SQL>selectchild_number,OPTIMIZER_ENV_HASH_VALUE,PLAN_HASH_VALUEfromv$SQLwhereSQL_ID='bxnnm7z1qmg26';CHILD_NUMBEROPTIMIZER_ENV_HASH_VALUEPLAN_HASH_VALUE---------------------------------------------------037041287403956160932136364789583956160932
注意V$SQLAREA.VERSION_COUNT未必等于selectcount(*)FROMV$SQLWHERESQL_ID=”，即V$SQLAREA.VERSION_COUNT显示的子游标数目未必等于当前实例中还存有的子游标数目，由于sharedpoolagedout算法和其他一些可能导致游标失效的原因存在，所以子游标被清理掉是很常见的事情。V$SQLAREA.VERSION_COUNT只是一个计数器，它告诉我们曾经生成了多少个childcursor，但不保证这些child都还在sharedpool里面。
此外可以通过v$SQL的child_number字段来分析该问题，如果child_number存在跳号则也说明了部分child被清理了。
子游标过多的影响，当子游标过多(例如超过3000个时),进程需要去扫描长长的子游标列表childcursorlist以找到一个合适的子游标childcursor，进而导致cursorsharing性能问题现大量的Cursor:MutexS和librarycachelock等待事件。
HashValue:共享SQL的哈希值
OnlyStatementswithVersionCountgreaterthan20aredisplayed注意该环节仅列出versioncount>20的语句
SQLorderedbyClusterWaitTimeDB/Inst:ITSCMP/itscmp2Snaps:70719-70723->%Total-ClusterTimeasapercentageofTotalClusterWaitTime->%Clu-ClusterTimeasapercentageofElapsedTime->%CPU-CPUTimeasapercentageofElapsedTime->%IO-UserI/OTimeasapercentageofElapsedTime->OnlySQLwithClusterWaitTime>.005secondsisreported->TotalClusterWaitTime(s):525,480->CapturedSQLaccountfor57.2%ofTotalClusterElapsedWaitTime(s)Executions%TotalTime(s)%Clu%CPU%IOSQLId-------------------------------------------------------------------------132,639.338,84825.2181,411.373.1.0.1g0yc9szpuu068
OnlySQLwithClusterWaitTime>.005secondsisreported这个环节仅仅列出ClusterWaitTime>0.005s的SQL
%Total:该SQL所消耗的ClusterWaittime占总的ClusterWaittime的比率，为(SQLclusterwaittime/DBtotalclusterWaitTime)
%Clu:该SQL所消耗的ClusterWaittime占该SQL总的耗时的比率，为(SQLclusterwaittime/SQLelapsedTime),该指标说明了该语句是否是集群等待敏感的
InstanceActivityStatsDB/Inst:ITSCMP/itscmp2Snaps:70719-70723->OrderedbystatisticnameStatisticTotalperSecondperTrans-----------------------------------------------------------------------------BatchedIO(bound)vectorcount450,449124.61.8BatchedIO(full)vectorcount5,4851.50.0BatchedIO(space)vectorcount1,4670.40.0BatchedIOblockmisscount4,119,0701,139.716.7BatchedIObufferdefragcount39,71011.00.2BatchedIOdoublemisscount297,35782.31.2BatchedIOsameunitcount1,710,492473.37.0BatchedIOsingleblockcount329,52191.21.3BatchedIOslowjumpcount47,10413.00.2BatchedIOvectorblockcount2,069,852572.78.4BatchedIOvectorreadcount262,16172.51.1BlockCleanoutOptimreferenced37,57410.40.2CCursor+sqlareaevicted1,4570.40.0...............
InstanceActivityStats的数据来自于DBA_HIST_SYSSTAT，DBA_HIST_SYSSTAT来自于V$SYSSTAT。
这里每一个指标都代表一种数据库行为的活跃度，例如redosize是指生成redo的量，sorts(disk)是指磁盘排序的次数，tablescans(directread)是指直接路径扫描表的次数。
虽然这些指标均只有Total、perSecond每秒、perTrans每事务三个维度，但对诊断问题十分有用。
我们来举几个例子：
1、例如当TopEvent中存在directpathread为Top等待事件，则需要分清楚是对普通堆表的directread还是由于大量LOB读造成的directpathread，这个问题可以借助tablescans(directread)、tablescans(longtables)、physicalreadsdirect、physicalreadsdirect(lob)、physicalreadsdirecttemporary几个指标来分析，假设physicalreadsdirect>>远大于physicalreadsdirect(lob)+physicalreadsdirecttemporary，且有较大的tablescans(directread)、tablescans(longtables)(注意这2个指标代表的是扫描表的次数不同于上面的phsicalreads的单位为块数*次数)，则说明了是大表扫描引起的directpathread。
3、系统出现IO类型的等待事件为TOpFive例如dbfilesequential/scatteredread，我们需要通过AWR来获得系统IO吞吐量和IOPS:
physicalreadbytes主要是应用造成的物理读取(Totalsizeinbytesofalldiskreadsbyapplicationactivity(andnototherinstanceactivity)only.)而physicalreadtotalbytes则包括了rman备份恢复和后台维护任务所涉及的物理读字节数，所以我们在研究IO负载时一般参考physicalreadtotalbytes；以下4对指标均存在上述的关系
总的物理吞吐量/秒=physicalreadtotalbytes+physicalwritetotalbytes
总的物理IOPS=physicalreadtotalIOrequests+physicalwritetotalIOrequests
IO的主要指标吞吐量、IOPS和延迟均可以从AWR中获得了，IO延迟的信息可以从UserI/O的WaitClassAvgWaittime获得，也可以参考11g出现的IOStatbyFunctionsummary
InstanceActivityStats有大量的指标，但是对于这些指标的介绍没有那一份文档有完整详尽的描述，即便在Oracle原厂内部要没有(或者是Maclean没找到)，实际是开发人员要引入某一个ActivityStats是比较容易的，并不像申请引入一个新后台进程那样麻烦，Oracle对于新版本中新后台进程的引入有严格的要求，但ActivityStats却很容易，往往一个one-offpatch中就可以引入了，实际上ActivityStats在源代码层仅仅是一些计数器。’
InstanceActivityStats-AbsoluteValuesSnaps:7071->Statisticswithabsolutevalues(shouldnotbediffed)StatisticBeginValueEndValue--------------------------------------------------------------sessionpgamemorymax1.157882826E+121.154290304E+12sessioncursorcachecount157,042,373157,083,136sessionugamemory5.496429019E+145.496775467E+14openedcursorscurrent268,916265,694workareamemoryallocated827,704837,487logonscurrent2,6092,613sessionugamemorymax1.749481584E+131.749737418E+13sessionpgamemory4.150306913E+114.150008177E+11
InstanceActivityStats–AbsoluteValues是显示快照起点和终点的一些指标的绝对值
InstanceActivityStats-ThreadActivityDB/Inst:G10R25/G10R25Snaps:3663-3->Statisticsidentifiedby'(derived)'comefromsourcesotherthanSYSSTATStatisticTotalperHour-----------------------------------------------------------logswitches(derived)172,326.47
reads:指该表空间上发生的物理读的次数(单位不是块，而是次数)
AvReads/s:指该表空间上平均每秒的物理读次数(单位不是块，而是次数)
AvRd(ms):指该表空间上每次读的平均读取延迟
Writes:该表空间上发生的物理写的次数;对于那些Writes总是等于0的表空间不妨了解下是否数据为只读，如果是可以通过readonlytablespace来解决RAC中的一些性能问题。
AvWrites/s:指该表空间上平均每秒的物理写次数
bufferWaits:该表空间上发生bufferbusywaits和readbyothersession的次数(9i中bufferbusywaits包含了readbyothersession)。
Tablespace表空间名
FileName数据文件的路径
Reads:该数据文件上累计发生过的物理读次数，不是块数
AvReads/s:该数据文件上平均每秒发生过的物理读次数，不是块数
AvRd(ms):该数据文件上平均每次物理读取的延迟，单位为ms
AvBlks/Rd:该数据文件上平均每次读取涉及到的块数，OLTP环境该值接近1
Writes:该数据文件上累计发生过的物理写次数，不是块数
AvWrites/s:该数据文件上平均每秒发生过的物理写次数，不是块数
bufferWaits:该数据文件上发生bufferbusywaits和readbyothersession的次数(9i中bufferbusywaits包含了readbyothersession)。
若某个表空间上有较高的IO负载，则有必要分析一下是否其所属的数据文件上的IO较为均匀还是存在倾斜，是否需要结合存储特征来将数据均衡分布到不同磁盘上的数据文件上，以优化I/O
Ppool池的名字D:默认的缓冲池defaultbufferpool,K:KeepPool,R:RecyclePool;2k4k8k16k32k:代表各种非标准块大小的缓冲池
Numberofbuffers:实际的缓冲块数目，约等于池的大小/池的块大小
PoolHit%:该缓冲池的命中率
BufferGets:对该缓冲池的中块的访问次数包括consistentgets和dbblockgets
PhysicalReads:该缓冲池BufferCache引起了多少物理读，其实是physicalreadscache，单位为块数*次数
PhysicalWrites：该缓冲池中Buffercache被写的物理写，其实是physicalwritesfromcache，单位为块数*次数
FreeBufferWaits:等待空闲缓冲的次数，可以看做该bufferpool发生freebufferwaits等待的次数
WriteCompWait:等待DBWR写入脏buffer到磁盘的次数，可以看做该bufferpool发生writecompletewaits等待的次数
BufferBusyWaits:该缓冲池发生bufferbusywait等待的次数
MTTRWrites:为了满足FAST_START_MTTR_TARGET指定的MTTR值而做出的物理写WRITES_MTTR
LogSizeWrites：由于最小的redologfile而做出的物理写WRITES_LOGFILE_SIZE
LogCkptwrites:由于LOG_CHECKPOINT_INTERVAL和LOG_CHECKPOINT_TIMEOUT驱动的增量检查点而做出的物理写WRITES_LOG_CHECKPOINT_SETTINGS
OtherSettingsWrites：由于其他设置(例如FAST_START_IO_TARGET）而引起的物理写，WRITES_OTHER_SETTINGS
AutotuneCkptWrites:由于自动调优检查点而引起的物理写，WRITES_AUTOTUNE
ThreadCkptWrites：由于threadcheckpoint而引起的物理写，WRITES_FULL_THREAD_CKPTB代表开始点，E代表结尾
RecoveryEstdIOs：实际是当前buffercache中的脏块数量，一旦实例崩溃这些脏块要被前滚
ActualRedoBlks：当前实际需要恢复的redo重做块数量
TargetRedoBlks：是LogSzRedoBlks、LogCkptTimeoutRedoBlks、LogCkptIntervalRedoBlks三者的最小值
OptLogSz(M):基于FAST_START_MTTR_TARGET而估算出来的redologfile的大小，单位为MB。Oracle官方推荐创建的重做日志大小至少大于这个估算值
缓冲池的颗粒大小可以参考SELECT*FROMV$SGAINFOwherenamelike(‘Granule%’);P指缓冲池的名字可能包括有Ddefaultbufferpool,KKeepPool,RrecyclePool
SizeForEst(M):指以该尺寸的bufferpool作为评估的对象，一般是目前currentsize的10%~200%，以便了解bufferpool增大~减小对物理读的影响
SizeFactor:尺寸因子，只对应bufferpool大小对当前设置的比例因子，例如current_size是100M，则如果评估值是110M那么sizeFactor就是1.1
Buffers(thousands)：指这个bufferpool尺寸下的buffer数量，要乘以1000才是实际值
EstPhysReadFactor：评估的物理读因子，例如当前尺寸的bufferpool会引起100个物理读，则别的尺寸的bufferpool如果引起120个物理读，那么对应尺寸的EstPhysReadFactor就是1.2
EstimatedPhysReads(thousands)：评估的物理读数目，要乘以1000才是实际值，显然不同尺寸的bufferpool对应不同的评估的物理读数目
Est%DBtimeforRds：评估的物理读占DBTIME的比率
我们看bufferpooladvisory一般有2个目的：
注意SizeFactor和EstPhysReadFactor之间不是简单的线性关系，所以需要人为介入评估得失
PGACacheHit%:指W/AWorkArea工作区的数据仅在内存中处理的比率，PGA缓存命中率
workarea是PGA中负责处理排序、哈希连接和位图合并操作的区域;workarea也叫做SQL作业区域
W/AMBprocesses:指在Workarea中处理过的数据的量，单位为MB
ExtraW/AMBRead/Written:指额外从磁盘上读写的工作区数据，单位为MB
AutoPGATarget(M):在自动PGA管理模式下实际可用的工作区内存“aggregatePGAautotarget“，因为PGA还有其他用途，不能全部作为workareamemory
PGAMemAlloc(M)：目前已分配的PGA内存，alloc不等于inuse即分配的内存不等于在使用的内存，理论上PGA会将确实不使用的内存返回给OS(PGAmemoryfreedbacktoOS)，但是存在PGA占用大量内存而不释放的场景
在上例中pga_aggregate_target仅为8192M，而实际processes在2,615~8000之间，如果一个进程耗费5MB的PGA也需要10000M的PGA，而实际这里PGAMemAlloc(M)是23,690M，这说明存在PGA的过载，需要调整pga_aggregate_target
W/APGAUsed(M)：所有的工作区workarea(包括manual和auto)使用的内存总和量，单位为MB
%PGAW/AMem:分配给workarea的内存量占总的PGA的比例，(W/APGAUsed)/PGAMemAlloc
%AutoW/AMem:AUTO自动工作区管理所控制的内存(workarea_size_policy=AUTO)占总的workarea内存的比例
%ManW/AMem:MANUAL手动工作区管理所控制的内存(workarea_size_policy=MANUAL)占总的workarea内存的比例
GlobalMemBound(K):指在自动PGA管理模式下一个工作区所能分配的最大内存(注意一个SQL执行过程中可能有多个工作区workarea)。GlobalMemBound(K)这个指标在实例运行过程中将被持续性的修正，以反应数据库当时工作区的负载情况。显然在有众多活跃工作区的系统负载下相应地GlobalMemBound将会下降。但应当保持globalbound值不要小于1MB，否则建议调高pga_aggregate_target
LowOptimal：此行所包含工作区workarea最适合内存要求的下限
HighOptimal：此行所包含工作区workarea最适合内存要求的上限
TotalExecs:在LowOptimal~HighOptimal范围工作区内完成的总执行数
Optimalexecs:optimal执行是指完全在PGA内存中完成的执行次数
1-passExecs:指操作过程中仅发生1次磁盘读取的执行次数
M-passExecs:指操作过程中发生了1次以上的磁盘读取，频发磁盘读取的执行次数
PGATargetEst(MB)用以评估的PGA_AGGREGATE_TARGET值
SizeFactr，当前用以评估的PGA_AGGREGATE_TARGET和当前实际设置的PGA_AGGREGATE_TARGET之间的比例因子PGATargetEst/PGA_AGGREGATE_TARGE
W/AMBProcessed：workarea中要处理的数据量，单位为MB
EstdExtraW/AMBRead/WrittentoDisk:以one-pass、M-Pass方式处理的数据量预估值，单位为MB
EstdPCacheHit%:预估的PGA缓存命中率
EstdPGAOverallocCount:预估的PGA过载量，如上文所述PGA_AGGREGATE_TARGET仅是一个目标值，无法真正限制PGA内存的使用，当出现PGA内存硬性需求时会产生PGAoverallocate过载(WhenusingAutoMemoryMgmt,minimallychooseapga_aggregate_targetvaluewhereEstdPGAOverallocCountis0)
SharedPoolSize(M):用以评估的sharedpool共享池大小，在AMM/ASMM环境下shared_pool大小都可能浮动
SPSizeFactr：共享池大小的比例因子，（SharedPoolSizeforEstim/SHARED_POOL_SIZE）
EstdLCSize(M):评估的librarycache大小，单位为MB，因为是sharedpool中包含librarycache当然还有其他例如rowcache
EstLCMemObj指评估的指定大小的共享池内的librarycachememoryobject的数量ESTD_LC_MEMORY_OBJECTS
EstLCTimeSavedFactr:EstLCTimeSaved(s)的比例因子，(EstLCTimeSaved(s)/CurrentLCTimeSaved(s))ESTD_LC_TIME_SAVED_FACTOR
EstLCLoadTime(s):在指定的共享池大小情况下解析的耗时
EstLCLoadTimeFactr：EstLCLoadTime(s)的比例因子，(EstLCLoadTime(s)/CurrentLCLoadTime(s))ESTD_LC_LOAD_TIME_FACTOR
EstLCMemObjHits(K):在指定的共享池大小情况下需要的librarycachememoryobject正好在共享池中被找到的次数ESTD_LC_MEMORY_OBJECT_HITS；
SGAtargetSize:用以评估的sgatarget大小(sga_target)
SGASizeFactor:SGASize的比例因子，(estSGAtargetSize/CurrentSGAtargetSize)
EstDBTime(s):评估对应于该指定sgatargetsize会产生多少量的DBTIME，单位为秒
EstPhysicalReads：评估对应该指定的sgatargetsize会产生多少的物理读
StreamsPoolAdvisoryDB/Inst:ITSCMP/itscmp2Snap:70723SizeforSizeEstSpillEstSpillEstUnspillEstUnspillEst(MB)FactorCountTime(s)CountTime(s)---------------------------------------------------------------640.500001281.000001921.500002562.000003202.500003843.000004483.500005124.000005764.500006405.000007045.500007686.000008326.500008967.000009607.500001,0248.000001,0888.500001,1529.000001,2169.500001,28010.00000
SizeforEst(MB):用以评估的streamspool大小
SizeFactor：streamspool大小的比例因子
EstSpillCount：评估出的当使用该大小的流池时message溢出到磁盘的数量ESTD_SPILL_COUNT
EstSpillTime(s)：评估出的当使用该大小的流池时message溢出到磁盘的耗时，单位为秒ESTD_SPILL_TIME
EstUnspillCount：评估的当使用该大小的流池时messageunspill即从磁盘上读取的数量ESTD_UNSPILL_COUNT
EstUnspillTime(s)：评估的当使用该大小的流池时messageunspill即从磁盘上读取的耗时，单位为秒ESTD_UNSPILL_TIME
该环节是对缓冲池中各类型(class)块等待的汇总信息，wait的原因一般是bufferbusywaits和readbyothersession
class数据块的class，一个oracle数据块即有class属性还有type属性，数据块中记录type属性(KCBH)，而在bufferheader里存有class属性(X$BH.class)
Waits:该类型数据块的等待次数
AvgTime(ms):该类型数据块平均每次等待的耗时，单位ms
如果用户正使用undo_management=AUTO的SMU则一般不会因为rollbacksegment过少而引起undoheaderblock类块的等待
对于INSERT而引起的buffer争用等待：
1、对于手动segment管理MSSM考虑增加Freelists、FreelistGroups
2、使用ASSM，当然ASSM本身没什么参数可调
对于INSERTONINDEX引起的争用：
EnqueueType(RequestReason)enqueue队列的类型，大家在研究enqueue问题前至少搞清楚enqueuetype和enqueuemode，enqueuetype是队列锁所要保护的资源如TM表锁CF控制文件锁，enqueuemode是持有队列锁的模式(SS、SX、S、SSX、X)
Requests:申请对应的enqueuetype资源或者队列转换(enqueueconversion例如S转SSX)的次数
SuccGets：对应的enqueue被成功申请或转换的次数
FailedGets：对应的enqueue的申请或者转换失败的次数
Waits：由对应的enqueue的申请或者转换而造成等待的次数
主要的enqueue等待事件：
UndoExtent有三种状态active、unexpired、expired
active=>extent中包括了活动的事务，active的undoextent一般不允许被其他事务重用覆盖
NumUndoBlocks(K)指被消费的undo数据块的数量,(K)代表要乘以1000才是实际值；可以用该指标来评估系统对undoblock的消费量，以便基于实际负载情况来评估UNDO表空间的大小
MaxTxConcy该时段内最大的事务并发量
STO/OOSSTO指ORA-01555SnapshotTooOld错误出现的次数；OOS–指OutofSpacecount错误出现的次数
uS–unexpiredStolen尝试从未过期的undoextent中偷取undospace的次数
uR–unexpiredReleased从未过期的undoextent中释放的块数目
uU–unexpiredreUsed未过期的undoextent中的block被其他事务重用的块数目
eS–expiredStolen尝试从过期的undoextent中偷取undospace的次数
eR–expiredReleased从过期的undoextent中释放的块数目
eU–expiredreUsed过期的undoextent中的block被其他事务重用的块数目
LatchActivitySnaps:70719-70723->"GetRequests","PctGetMiss"and"AvgSlps/Miss"arestatisticsforwilling-to-waitlatchgetrequests->"NoWaitRequests","PctNoWaitMiss"areforno-waitlatchgetrequests->"PctMisses"forbothshouldbeverycloseto0.0PctAvgWaitPctGetGetSlpsTimeNoWaitNoWaitLatchNameRequestsMiss/Miss(s)RequestsMiss--------------------------------------------------------------------------AQdeqhashtablelatch40.000N/AASMKeyedstatelatch9,0480.10.200N/AASMallocation15,0170.20.810N/AASMdbclientlatch72,7450.000N/AASMmapheaders5,8600.60.610N/AASMmaploadwaitinglis1,4620.000N/AASMmapoperationfreeli63,5390.10.410N/AASMmapoperationhasht76,484,4470.11.0660N/A
latchnameLatch闩的名字
GetRequestslatch被以willing-to-wait模式申请并获得的次数
PctGetMissmiss是指latch被以willing-to-wait模式申请但是申请者必须等待的次数，PctGetMiss=Miss/GetRequests;miss可以从后面的LatchSleepBreakdown获得
AvgSlps/MissSleep是指latch被以willing-to-wait模式申请最终导致session需要sleep以等待该latch的次数；AvgSlps/Miss=Sleeps/Misses;Sleeps可以从后面的LatchSleepBreakdown获得
NoWaitRequests指latch被以no-wait模式来申请的次数
PctNoWaitMiss以no-wait模式来申请latch但直接失败的次数
对于高并发的latch例如cachebufferschains，其PctMisses应当十分接近于0
一般的调优原则：
如果latch:cachebufferschains是Top5事件，则需要考虑优化SQL减少全表扫描并减少TopbuffergetsSQL语句的逻辑读
如果latch:redocopy、redoallocation等待较多，则可以考虑增大LOG_BUFFER
如果latch:librarycache发生较多，则考虑增大shared_pool_size
misses是指latch被以willing-to-wait模式申请但是申请者必须等待的次数
所以一般来说9i以后的misses=Sleeps+SpinGets，虽然不是绝对如此
Sleeps是指latch被以willing-to-wait模式申请最终导致session需要sleep以等待该latch的次数
SpinGets以willing-to-wait模式去申请latch，在miss之后以spin方式获得了latch的次数
latchnameLatch闩的名字where:指哪些代码路径内核函数持有过这些该latch，而不是哪些代码路径要申请这些latch；例如kcbgtcr函数的作用是GetablockforConsistentread，其持有latch:cachebufferschain是很正常的事情
NoWaitMisses:以no-wait模式来申请latch但直接失败的次数
Sleeps:指latch被以willing-to-wait模式申请最终导致session需要sleep以等待该latch的次数timeofsleepsresultedinmakingthelatchrequest
WaiterSleeps：等待者休眠的次数timesofsleepsthatwaitersdidforeachwhere;Sleep是阻塞者等待的次数，WaiterSleeps是被阻塞者等待的次数
MutexType
Mutex的类型其实就是mutex对应的客户的名字，在版本10.2中基本只有KKS使用Mutex，所以仅有3种:
11g中增加了LibraryCache
Location发起对该Mutex申请的代码路径codelocation，而不是还持有该Mutex的代码路径或曰内核函数
10.2中最常见的下面的几个函数
kkspsc0-负责解析游标–检测我们正在解析的游标是否有对象的parentcursorheap0存在
kksfbc–负责找到合适的子游标或者创建一个新的子游标
kksFindCursorstat
Sleeps:
若该Mutex在SPIN之后仍未被释放，则该进程针对申请的mutex进入对应的mutexwait等待事件中。实际进程的等待事件和等待方式由mutex的类型锁决定，例如Cursorpin、CursorParent。举例来说，这种等待可能是阻塞等待，也可以是sleep。
V$MUTEX_SLEEP_HISTORY视图的GETS列仅在成功申请到一个Mutex时才增加。
owner:数据段的所有者
TablespaceName:数据段所在表空间名
ObjectName:对象名
SubobjectName：子对象名，例如一个分区表的某个分区
objType:对象类型一般为TABLE/INDEX或者分区或子分区
LogicalReads：该数据段上发生过的逻辑读，单位为块数*次数
%Total:占总的逻辑读的百分比，(当前对象上发生过的逻辑读/TotalDB逻辑读)
PhysicalReads:该数据段上发生过的物理读，单位为块数*次数
%Total:占总的物理读的百分比，(当前对象上发生过的逻辑读/TotalDB逻辑读)
PhysReadRequests：物理读的申请次数
%Total：(该段上发生的物理读的申请次数/physicalreadIOrequests)
UnOptimizedReadsUnOptimizedReadReqs=PhysicalReadReqts–OptimizedReadReqs
OptimizedReadRequests是指哪些满足ExadataSmartFlashCache(ortheSmartFlashCacheinOracleExadataV2(Notethatdespitesamename,conceptanduseof‘SmartFlashCache’inExadataV2isdifferentfrom‘SmartFlashCache’inDatabaseSmartFlashCache)).的物理读次数。满足从smartflashcache走的读取申请呗认为是optimized，因为这些读取要比普通从磁盘走快得多。
当用户不在使用Exadata时，则UnOptimizedReadReqs总是等于PhysicalReadReqts
%Total:(该段上发生的物理读的UnOptimizedReadReqs/(physicalreadIOrequests–physicalreadrequestsoptimized))
SegmentsbyOptimizedReadsDB/Inst:MAC/MAC2Snaps:70719-70723->TotalOptimizedReadRequests:33,124,894->CapturedSegmentsaccountfor45.2%ofTotalTablespaceSubobjectObj.OptimizedOwnerNameObjectNameNameTypeReads%Total--------------------------------------------------------------------------CONTENT_OWDATA_TSMZ_CONTENT_PROVIDER_TABLE2,995,7669.04CONTENT_OWDATA_TSMZ_PRODUCT_ATTRIBUTETABLE1,489,0004.50CONTENT_OWDATA_TSMZ_PRODUCTTABLE1,276,3503.85CONTENT_OWDATA_TSMZ_AUDIO_FILETABLE890,7752.69CONTENT_OWINDEX_TSMZ_AM_REQUEST_IX3INDEX816,0672.46关于optimizerdread上面已经解释过了，这里的单位是request次数
%Total:(该段上发生的物理读的OptimizedReadReqs/physicalreadrequestsoptimized)
SegmentsbyDirectPhysicalReadsDB/Inst:MAC/MAC2Snaps:70719-70723->TotalDirectPhysicalReads:14,118,552->CapturedSegmentsaccountfor94.2%ofTotalTablespaceSubobjectObj.DirectOwnerNameObjectNameNameTypeReads%Total--------------------------------------------------------------------------CONTENT_OWSONG_TSMZ_SONGTABLE7,084,41650.18CONTENT_OWDATA_TSMZ_CS_WORK_PENDING_RTABLE4,839,98434.28CONTENT_OWDATA_TSMZ_PUBLICATIONTABLE1,361,1339.64CONTENT_OWDATA_TSSYS_LOB0000203660C00LOB5,904.04CONTENT_OWDATA_TSSYS_LOB0000203733C00LOB1,656.01Directreads直接路径物理读，单位为块数*次数%Total(该段上发生的directpathreads/Totalphysicalreadsdirect)
PhysicalWrites，物理写单位为块数*次数
Total%(该段上发生的物理写/Totalphysicalwrites)
PhysWriteRequests物理写的请求次数，单位为次数
%Total(该段上发生的物理写请求次数/physicalwriteIOrequests)
SegmentsbyDirectPhysicalWritesDB/Inst:MAC/MAC2Snaps:70719-70723->TotalDirectPhysicalWrites:29,660->CapturedSegmentsaccountfor18.3%ofTotalTablespaceSubobjectObj.DirectOwnerNameObjectNameNameTypeWrites%Total--------------------------------------------------------------------------SYSSYSAUXWRH$_ACTIVE_SESSION_1367_70520TABLE4,60115.51CONTENT_OWDATA_TSSYS_LOB0000203733C00LOB6202.09CONTENT_OWDATA_TSSYS_LOB0000203660C00LOB134.45CONTENT_OWDATA_TSSYS_LOB0000203779C00LOB46.16CONTENT_OWDATA_TSSYS_LOB0000203796C00LOB41.14DirectWrites直接路径写，单位额为块数*次数%Total为(该段上发生的直接路径写/physicalwritesdirect)
DBBlockChanges，单位为块数*次数
%Total:(该段上发生blockchanges/dbblockchanges)
SegmentsbyGlobalCacheBufferBusyDB/Inst:MAC/MAC2Snaps:70719-7072->%ofCaptureshows%ofGCBufferBusyforeachtopsegmentcompared->withGCBufferBusyforallsegmentscapturedbytheSnapshotGCTablespaceSubobjectObj.Buffer%ofOwnerNameObjectNameNameTypeBusyCapture--------------------------------------------------------------------------CONTENT_OWINDEX_TSMZ_AM_REQUEST_IX3INDEX2,135,52850.07CONTENT_OWDATA_TSMZ_CONTENT_PROVIDER_TABLE652,90015.31CONTENT_OWLOB_8K_TSMZ_ASSET_WORK_EVENT_INDEX552,16112.95CONTENT_OWLOB_8K_TSMZ_CS_WORK_NOTE_RE_I_2013_1_36INDEX113,0422.65CONTENT_OWLOB_8K_TSMZ_CS_WORK_INFO_PART_2013_5_35INDEX98,1342.30GCBufferBusy数据段上发挥僧gcbufferbusy的次数，数据源dba_hist_seg_stat.gc_buffer_busy_delta
%Total:(该段上在本节点接收的GlobalCRblocks/gccrblocksreceived)
%Total:(该段上在本节点接收的globalcachecurrentblocks/gccurrentblocksreceived)
DictionaryCacheStatsDB/Inst:MAC/MAC2Snaps:70719-70723->"PctMisses"shouldbeverylow(<2%inmostcases)->"FinalUsage"isthenumberofcacheentriesbeingusedGetPctScanPctModFinalCacheRequestsMissReqsMissReqsUsage-------------------------------------------------------------------------dc_awr_control872.30N/A61dc_global_oids1,1347.80N/A013dc_histogram_data6,119,0270.90N/A011,784dc_histogram_defs1,898,7142.30N/A05,462dc_object_grants17526.90N/A04dc_objects10,254,5140.20N/A03,807dc_profiles8,4520.00N/A02dc_rollback_segments3,031,0440.00N/A01,947dc_segments1,812,2431.40N/A103,595dc_sequences15,78369.60N/A15,78220dc_table_scns702.90N/A01dc_tablespaces1,628,1120.00N/A037dc_users2,037,1380.00N/A052globaldatabasename7,6980.00N/A01outstanding_alerts26499.60N/A81sch_lj_oids517.80N/A01
DictionaryCache字典缓存也叫rowcache
Cache字典缓存类名kqrstcid<=>kqrsttxtcid=3(dc_rollback_segments)
GetRequests申请获取该数据字典缓存对象的次数gets
Miss:GETMISSES申请获取该数据字典缓存对象但miss的次数
PctMiss：GETMISSES/Gets，Miss的比例，这个pctmiss应当非常低小于2%，否则有出现大量rowcachelock的可能
ScanReqs：扫描申请的次数，kqrssc、kqrpScan、kqrpsiv时发生scan会导致扫描数增加kqrstsrq++(scanrequests)，例如migratetablespace时调用kttm2b函数为了安全删除uet$中的记录会callbackkqrpsiv(usedextentcache)，实际很少见
PctMiss：SCANMISSES/SCANS
ModReqs:申请修改字典缓存对象的次数，从上面的数据可以看到dc_sequences的modreqs很高，这是因为sequence是变化较多的字典对象
FinalUsage：包含有有效数据的字典缓存记录的总数也就是正在被使用的rowcache记录USAGENumberofcacheentriesthatcontainvaliddata
DictionaryCacheStats(RAC)DB/Inst:MAC/MAC2Snaps:70719-70723GESGESGESCacheRequestsConflictsReleases-------------------------------------------------------------dc_awr_control1420dc_global_oids880102dc_histogram_defs43,518043,521dc_objects21,6081721,176dc_profiles101dc_segments24,9741424,428dc_sequences25,17810,644347dc_table_scns202dc_tablespaces1650166dc_users1190119outstanding_alerts4788250sch_lj_oids404
GESRequestkqrstilrtotalinstancelockrequests，通过全局队列服务GES来申请instancelock的次数
GESrequest申请的原因可能是dumpcacheobject、kqrbfrLCK进程要backgroundfreesomeparentobjects释放一些parentobjects等
GESConflictskqrstifrinstancelockforced-releases，LCK进程以AST方式释放锁的次数，仅出现在kqrbrl中
GESReleaseskqrstisrinstancelockself-releases，LCK进程要backgroundfreesomeparentobjects释放一些parentobjects时可能自增
在Oracle10g中，ORDEREDSequence还可能在高并发下造成大量DFSlockHandle等待，由于bug5209859
LibraryCacheActivityDB/Inst:MAC/MAC2Snaps:70719-70723->"PctMisses"shouldbeverylowGetPctPinPctInvali-NamespaceRequestsMissRequestsMissReloadsdations-----------------------------------------------------------------------ACCOUNT_STATUS8,4360.30N/A00BODY8,6970.715,5370.7490CLUSTER3174.73214.700DBLINK9,2120.10N/A00EDITION4,4310.08,6600.000HINTSETOBJECT1,0279.51,02714.400INDEX79218.279218.200QUEUE100.01,7330.000RULESET0N/A887.570SCHEMA8,1690.00N/A00SQLAREA533,4094.8-4,246,727,944101.144,864576SQLAREABUILD71,50065.50N/A00SQLAREASTATS41,00890.341,00890.310TABLE/PROCEDURE320,3100.61,033,9913.625,3780TRIGGER8470.038,4420.31100
NameSpacelibrarycache的命名空间
GETSRequests该命名空间所包含对象的librarycachelock被申请的次数
GETHITS对象的librarycachehandle正好在内存中被找到的次数
PctMisses:(1-(GETHITS/GETSRequests))*100
PinRequests该命名空间所包含对象上pin被申请的次数
PINHITS要pin的对象的heapmetadata正好在sharedpool中的次数
PctMiss(1-(PINHITS/PinRequests))*100
Reloads指从objecthandle被重建开始不是第一次PIN该对象的PIN，且该次PIN要求对象从磁盘上读取加载的次数;Reloads值较高的情况建议增大shared_pool_size
INVALIDATIONS由于以来对象被修改导致该命名空间所包含对象被标记为无效的次数
LibraryCacheActivity(RAC)DB/Inst:MAC/MAC2Snaps:70719-70723GESLockGESPinGESPinGESInvalGESInvali-NamespaceRequestsRequestsReleasesRequestsdations-------------------------------------------------------------------------ACCOUNT_STATUS8,4360000BODY015,49715,49700CLUSTER32132132100DBLINK9,2120000EDITION4,4314,4314,43100HINTSETOBJECT1,0271,0271,02700INDEX79279279200QUEUE81,7331,73300RULESET08800SCHEMA4,2260000TABLE/PROCEDURE373,163704,816704,81600TRIGGER038,43038,43000
GESLockRequest:dlm_lock_requestsLockinstance-lockReQuests申请获得lockinstancelock的次数
GESPINrequest:DLM_PIN_REQUESTSPininstance-lockReQuests申请获得pininstancelock的次数
GESPinReleasesDLM_PIN_RELEASESreleasethepininstancelock释放pininstancelock的次数
GESInvalRequestsDLM_INVALIDATION_REQUESTSgettheinvalidationinstancelock申请获得invalidationinstancelock的次数
GESInvali-dationsDLM_INVALIDATIONS接收到其他节点的invalidationpings次数
ProcessMemorySummaryDB/Inst:MAC/MAC2Snaps:70719-70723->B:BeginSnapE:EndSnap->Allrowsbelowcontainabsolutevalues(i.e.notdiffedovertheinterval)->MaxAllocisMaximumPGAAllocationsizeatsnapshottime->HistMaxAllocistheHistoricalMaxAllocationforstill-connectedprocesses->orderedbyBegin/Endsnapshot,Alloc(MB)descHistAvgStdDevMaxMaxAllocUsedAllocAllocAllocAllocNumNumCategory(MB)(MB)(MB)(MB)(MB)(MB)ProcAlloc---------------------------------------------------------------------BOther16,062.7N/A6.166.63,3703,3702,6122,612SQL5,412.24,462.92.289.54,4834,4832,5082,498Freeable2,116.4.0.96.3298N/A2,2662,266PL/SQL94.069.8.0.0112,6102,609EOther15,977.3N/A6.166.93,3873,3872,6162,616SQL5,447.94,519.02.289.84,5054,5052,5142,503Freeable2,119.9.0.96.3297N/A2,2732,273PL/SQL93.269.2.0.0112,6142,613
B:开始快照E:结束快照
该环节列出PGA中各分类的使用量
Category分类名，包括”SQL”,“PL/SQL”,“OLAP”和”JAVA”.特殊分类是“Freeable”和”Other”.Freememory是指哪些OS已经分配给进程，但没有分配给任何分类的内存。“Other”是已经分配给分类的内存，但不是已命名的分类
Alloc(MB)allocated_total该分类被分配的总内存
Used(MB)used_total该分类已使用的内存
AvgAlloc(MB)allocated_avg平均每个进程中该分类分配的内存量
StdDevAlloc(MB)：该分类分配的内存在每个进程之间的标准差
HistMaxAlloc(MB)MAX_ALLOCATED_MAX:目前仍链接着的进程该分类最大分配过的内存量：HistMaxAllocistheHistoricalMaxAllocationforstill-connectedprocesses
NumProcnum_processes进程数目
NumAllocNON_ZERO_ALLOCS分配了该类型内存的进程数目
SGAMemorySummaryDB/Inst:MAC/MAC2Snaps:70719-70723EndSize(Bytes)SGAregionsBeginSize(Bytes)(ifdifferent)--------------------------------------------------------------------DatabaseBuffers20,669,530,112FixedSize2,241,880RedoBuffers125,669,376VariableSize10,536,094,376-------------------sum31,333,535,744
粗粒度的sga区域内存使用信息，EndSize仅在于beginsize不同时打印
Pool内存池的名字
Name内存池中细分组件的名字例如KGLH0存放KELHeap0、SQLA存放SQL执行计划等
BeginMB快照开始时该组件的内存大小
EndMB快照结束时该组件的内存大小
%Diff差异百分比
特别注意由于AMM/ASMM引起的sharedpool收缩一般在sgabreakdown中可以提现例如SQLA、KQR等组件大幅缩小，可能导致一系列的解析等待cursor:PinSonX、rowcachelock等
CaptureName:Streams捕获进程名
CapturedPerSecond：每秒挖掘出来的message条数
EnqueuedPerSecond:每秒入队的message条数
ApplyNameStreams应用Apply进程的名字
AppliedTPS:每秒应用的事务数
PctDB:所有的DB事务中apply处理的比例
PctRBK:事务rollback回滚的比例
AppliedMPS:每秒应用的message数
DequeueTPM:每毫秒出队的message数
ResourceLimitStatsDB/Inst:MAC/MAC2Snap:70723->onlyrowswithCurrentorMaximumUtilization>80%ofLimitareshown->orderedbyresourcenameCurrentMaximumInitialResourceNameUtilizationUtilizationAllocationLimit--------------------------------------------------------------------------ges_procs2,6128,0071000310003processes2,6158,0111000010000
数据源于dba_hist_resource_limit
注意这里仅列出当前使用或最大使用量>80%*最大限制的资源名，如果没有列在这里则说明资源使用量安全CurrentUtilization当前对该资源(包括EnqueueResource、Lock和processes)的使用量
MaximumUtilization从最近一次实例启动到现在该资源的最大使用量
InitialAllocation初始分配值，一般等于参数文件中指定的值
Limit实际上限值
init.oraParametersDB/Inst:MAC/MAC2Snaps:70719-70723EndvalueParameterNameBeginvalue(ifdifferent)----------------------------------------------------------------------------_compression_compatibility11.2.0_kghdsidx_count4_ksmg_granule_size67108864_shared_pool_reserved_min_all4100archive_lag_target900audit_file_dest/u01/app/oracle/admin/MAC/adumaudit_trailOScluster_databaseTRUEcompatible11.2.0.2.0control_files+DATA/MAC/control01.ctl,+RECOdb_16k_cache_size268435456db_block_size8192db_cache_size19327352832db_create_file_dest+DATA
ParameterName参数名
Beginvalue开始快照时的参数值
Endvalue结束快照时的参数值(仅在发生变化时打印)
GlobalCRServedStatsDB/Inst:MAC/MAC2Snaps:70719-70723StatisticTotal------------------------------------------------CRBlockRequests403,703CURRENTBlockRequests444,896DataBlockRequests403,705UndoBlockRequests94,336TXBlockRequests307,896CurrentResults652,746Privateresults21,057ZeroResults104,720DiskReadResults69,418FailResults508FairnessDownConverts102,844FairnessClears15,207FreeGCElements0Flushes105,052FlushesQueued0FlushQueueFull0FlushMaxTime(us)0LightWorks71,793Errors117
GlobalCURRENTServedStatsDB/Inst:MAC/MAC2Snaps:70719-70723->Pins=CURRENTBlockPinOperations->Flushes=RedoFlushbeforeCURRENTBlockServedOperations->Writes=CURRENTBlockFusionWriteOperationsStatisticTotal%<1ms%<10ms%<100ms%<1s%<10s--------------------------------------------------------------Pins73,01812.2775.968.492.211.08Flushes79,3365.9850.1714.4519.459.95Writes102,1893.1435.2319.3433.269.03
Timetoprocesscurrentblockrequest=(pintime+flushtime+sendtime)
PinsCURRENTBlockPinOperations，PIN的内涵是处理一个BAST不包含对globalcurrentblock的flush和实际传输
ThepintimerepresentshowmuchtimeisrequiredtoprocessaBAST.Itdoesnotincludetheflushtimeandthesendtime.Theaveragepintimeperblockservedshouldbeverylowbecausetheprocessingconsistsmainlyofcodepathandshouldneverbeblocked.
Write指fusionwritenumberofwriteswhichweremediated；节点之间写脏块需求相互促成的行为KJBL.KJBLREQWRITEgcswriterequestmsgs、gcswritesrefused
%<1ms%<10ms%<100ms%<1s%<10s分别对应为pin、flush、write行为耗时的比例
例如在上例中flush和write在1s到10s之间的有9%，在100ms和1s之间的有19%和33%，因为flush和write都是IO操作所以这里可以预见IO存在问题，延迟较高
InstNo节点号
BlockClass块的类型
CRBlocksReceived该节点上该类型CR块的接收数量
CRImmed%:CR块请求立即接收到的比例
CRBusy%：CR块请求由于远端争用而没有立即接收到的比例
CRCongst%:CR块请求由于远端负载高而没有立即接收到的比例
CurrentBlocksReceived该节点上该类型Current块的接收数量
CurrentImmed%:Current块请求立即接收到的比例
CurrentBusy%：Current块请求由于远端争用而没有立即接收到的比例
CurrentCongst%:Current块请求由于远端负载高而没有立即接收到的比例
Congst%的比例应当非常低不高于2%，Busy%很大程度受到IO的影响，如果超过10%一般会有严重的gcbufferbusyacquire/release
GlobalCacheLoadProfile
+((‘gcsmessagessent’+‘gesmessagessent’+‘gcsmsgsreceived’+‘gcsmsgs
received’)*200)/1024/ElapsedTime
GlobalCacheEfficiencyPercentages(Targetlocal+remote100%)
GlobalCacheandEnqueueServices–WorkloadCharacteristics