Oracle-AWR-报告分析实例讲解

WORKLOADREPOSITORYreportforDBTime是记录在服务器花在数据库运算（非后台进程）和等待（非空闲等待）DBTime是记录在服务器花在数据库运算（非后台进程）和等待（非空闲等待）上的时间DBTime=cputime+waittime（不包含空闲等待）（非后台进程）DBTime不包括Oracle后台进程消耗的时间。如果DBTime远远小于Elapsed时间，说明数据库比较空闲。上述报表中Snapshot时间间隔约为79分钟，cpu就公有8*79=632分钟。DBTime为11.05分钟，则：cpu花费了11.05分钟在处理oracle非空闲等待和运算上（比如逻辑读），也就是说cpu有11.05/632=0.017%花费在处理oracle的操作上。从awrreport的Elapsedtime和DBTime就能大概了解db的负载，计算公式可参考为：cpu负载=DBTime/（cpu数*Elapsed）*100%在79分钟里（其间收集了3次快照数据），数据库耗时11分钟，RDA数据中显示系统有8个逻辑CPU（4个物理CPU），平均每个CPU耗时1.4分钟，CPU利用率只有大约2%（1.4/79）。说明系统压力非常小。可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。ReportSummaryCacheSizesBeEndBeBufferCache: 3,344M 3,344MStdBlockSize: 8KSharedPoolSize: 704MI704MLogBuffer: 14,352K显示SGA中每个区域的大小（在AMM改变它们之后），可用来与初始参数值比较。sharedpool主要包括librarycache和dictionarycache。librarycache用来存储最近解析（或编译）后SQL、PL/SQL和Javaclasses等。librarycache用来存储最近引用的数据字典。发生在librarycache或dictionarycache的cachemiss代价要比发生在buffercache的代价高得多。因此sharedpool的设置要确保最近使用的数据都能被cache。LoadProfileDBTime(s)2.40.0Redosize:918,805.72775,912.72Logicalreads:3,521.772,974.06Blockchanges:1,817.951,535.22Physicalreads:68.2657.64Physicalwrites:362.59306.20Usercalls:326.69275.88Parses:38.6632.65Hardparses:0.030.03Sorts:0.610.51Logons:0.010.01Executes:354.34299.23Transactions:1.18%BlockschangedperRead:51.62RecursiveCall%: 51.72Rollbackpertransaction%:85.49RowsperSort: ########显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，然而Logons大于每秒1~2个、Hardparses大于每秒100、全部parses超过每秒300表明可能有争用问题。DBTime（s）:每秒内用于DB处理的时间，其他时间为等待时间Redosize:每秒/每事务产生的redo大小（单位字节），可标志数据库任务的繁重程序。其中PerSecond表示每秒中产生的redo的字节数，PerTransaction表示每个事务产生的redo的字节数，可以通过后者可以看到事务的大小，协助判断是否commit次数太多。例如persecond很大，而pertransaction很小，说明commit次数太多。通常在很繁忙的系统中日志生成量可能达到上百k，甚至几百k。Logicalreads：每秒/每事务逻辑读的块数（我们可以这样认为，block在内存中，我们每一次读一块内存，就相当于一次逻辑读），单位为块，在良好的OLTP环境中，Logicalreads/Executes不会超过50，一般只有10左右，如果该指标较大，表示语句可能不够优化，需要具体分析，在该示例中，3,521.77/354.34，那么在OLAP中呢？Blockchanges:每秒/每事务修改的块数，即每秒中多少个块发生变化Physicalreads：每秒/每事务物理读的块数，即每秒数据库从磁盘读取的块个数Physicalwrites:每秒/每事务物理写的块数，即每秒有多少个块接受了数据库写入数据。Usercalls:每秒/每事务用户call次数Usercalls/Executes基本代表每个语句的请求次数，Executes越接近Usercalls越好。Parses:每秒的SQL语句解析的次数，超过300即需要关注，可以考虑调整参数session_cursor_cache来改善解析次数过高的现象。Hardparses:其中硬解析的次数，如果硬解析次数太高，说明SQL重用率不高。例如超过100,基本都是由于不使用bindvar所导致的，导致cpu使用率的问题，极有使得性能急剧下降。Sorts:每秒/每事务的排序次数Logons:每秒/每事务登录的次数Executes：每秒/每事务SQL执行次数，包括用户执行的sql语句与系统执行的sql语句，表示一个系统sql的繁忙程度。Transactions:每秒产生的事物个数，反映数据库负载程度，不同的系统，略有差异，在典型的交易系统中，事务较多，而网站系统，可能select查询较多。BlockschangedperRead:表示逻辑读用于修改数据块的比例RecursiveCall:递归调用占所有操作的比率Rollbackpertransaction:每事务的回滚率Rollbacks：表示数据库中事务的回退率，如果不是因为业务本身的原因，通常应该小于10%为好，回退是一个很消耗资源的操作。RowsperSort:每次排序的行数注：Oracle的硬解析和软解析提到软解析(softparse)和硬解析(hardparse)，就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程：1、 语法检查(syntaxcheck)检查此sql的拼写是否语法。2、 语义检查(semanticcheck)诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。3、 对sql语句进行解析(parse)利用内部算法对sql进行解析，生成解析树(parsetree)及执行计划(executionplan)。4、 执行sql，返回结果(executeandreturn)其中，软、硬解析就发生在第三个过程里。Oracle利用内部的hash算法来取得该sql的hash值，然后在librarycache里查找是否存在该hash值；假设存在，则将此sql与cache中的进行比较；假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。诚然，如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。 创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。InstanceEfficiencyPercentages(Target100%)BufferNowait%:100.00RedoNoWait%:100.00BufferHit%：98.72In-memorySort%,一99.86LibraryHit%:99.97SoftParse%:99.92ExecutetoParse%:89.09LatchHit%:99.99ParseCPUtoParseElapsd%: 7.99%Non-ParseCPU: 99.95本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中BufferHitRatio也称CacheHitRatio，LibraryHitratio也称LibraryCacheHitratioo同LoadProfile一节相同，这一节也没有所谓"正确"的值，而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的DSS环境，20%的BufferHitRatio是可以接受的，而这个值对于一个OLTP系统是完全不能接受的。根据Oracle的经验，对于OLTPT系统，BufferHitRatio理想应该在90%以上。BufferNowait%表示在数据缓冲区中获取的buffer时，未进行等待的比率，越高越好。bufferhit%表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，命中率通常在95@以上，如果此值低于80%，应该给数据库分配更多的内存，考虑加大db_cache_size。在数据仓库OLAP环境中，数据缓冲命中率不是一个重要的指标，因为OLAP数据库主要是物理读，甚至是直接读，该命中率不可能高。RedoNoWai%t表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOGBUFFERolibraryhit%表示Oracle从LibraryCache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查LibraryCache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在LibraryCache中为它分配共享SQL区。低的libraryhitratio会导致过多的解析，增加CPU消耗，降低性能。Sql语句在库缓冲中能否找到相应的解析计划，如果libraryhitratio低于90%，可能需要调大sharedpool区，或检查是否有硬编码现象。LatchHit%：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可，表示内部结构维护锁命中率。要确保LatchHit>99%，否则意味着SharedPoollatch争用，可能由于未共享的SQL，或者LibraryCache太小，可使用绑定变更或调大SharedPool解决。ParseCPUtoParseElapsd：表示解析实际运行时间/（解析实际运行时间+解析中等待资源时间），越高越好。在实际繁忙的系统中，该值可能因为等待资源而不会太咼。Non-ParseCPU:SQL实际运行时间/（SQL实际运行时间+SQL解析时间），太低表示解析消耗时间过多。说明解析时间所占比率过高，需要考虑提高sql语句重用性。ExecutetoParse:是语句执行与分析的比例，表示sql语句解析后被重复执行的命中率，计算公式=100*（1-Parses/Executions）,如果该值偏小，说明分析（硬分析和软分析）的比例较大，快速分析较少，根据实际情况，可以考虑调整session_cached_cursors参数，有些报告中这个值是负的，看上去很奇怪，事实上这表示一个问题,sql如果被ageout的话就可能出现这种情况，也就是sql老化，执行altersystemflushshared_pool如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。SoftParse%：SQL语句软解析占整个分析的命中率，如果低于95,需检查是否有硬编码现象，如果低于80，说明sql语句基本没有重用性=soft/（soft+hard）In-memorySort:在内存中排序的比率，即有多少排序在内存中进行的，如果过低说明有大量的排序在临时表空间中进行，性能肯定不好，考虑调大PGA参数，sort_area_size0SoftParse:软解析的百分比(softs/softs+hards)，近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。End1MemoryUsage%:47.1947.50%SQLwithexecutions>1:88.48End1MemoryUsage%:47.1947.50%SQLwithexecutions>1:88.4879.81%MemoryforSQLw/exec>1:79.9973.52 MemoryUsage%:表示共享池内存使用率，对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明SharedPool有浪费，而如果高于90,说明共享池中有争用，内存不足。SQLwithexecutions>1:执行次数大于1的sql比率，如果此值太小的话要结合Parse，看看是不是硬编码现象，说明需要在应用中更多使用绑定变量，避免过多SQL解析。MemoryforSQLw/exec>1：执行次数大于1的SQL消耗内存的占比。Top5TimedEventsCPUtime51577.6SQL*Netmoredatafromclient27,3196429.7Networklogfileparallelwrite5,4974797.1SystemI/Odbfilesequentialread7,9003545.3UserI/Odbfileparallelwrite4,8063475.1SystemI/O这是报告概要的最后一节，显示了系统中最严重的5个等待，按所占等待时间的比例倒序列示。当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。例如如果'bufferbusywa是;较严重的等待事件,我们应当继续研究报告中BufferWait和File/TablespaceIO区的内容，识别哪些文件导致了问题。如果最严重的等待事件是I/O事件，我们应当研究按物理读排序的SQL语句区以识别哪些语句在执行大量I/O,并研究Tablespace和I/O区观察较慢响应时间的文件。如果有较高的LATCH等待，就需要察看详细的LATCH统计识别哪些LATCH产生的问题。在这里，logfileparallelwrite是相对比较多的等待，占用了7%的CPU时间。通常，在没有问题的数据库中，CPUtime总是列在第一个。更多的等待事件，参见本报告的WaitEvents一节。NumberofInstances:22RACStatistics

GlobalCacheLoadProfileGlobalCacheblocksreceived:4.163.51GlobalCacheblocksserved:5.975.04GCS/GESmessagesreceived:408.47344.95GCS/GESmessagessent:258.03217.90DBWRFusionwrites:0.050.05EstdInterconnecttraffic(KB)211.16p(PerTrGlobalCacheEfficiencyPercentages(Targetlocal+remote100%)Bufferaccess-localcache%:98.60Bufferaccess-remotecache%:0.12Bufferaccess-disk%:1.28GlobalCacheandEnqueueServices-WorkloadCharacteristicsAvgglobalenqueuegettime(ms):Avgglobalcachecrblockreceivetime(ms):Avgglobalcachecurrentblockreceivetime(ms):Avgglobalcachecrblockbuildtime(ms):Avgglobalcachecrblocksendtime(ms):Globalcachelogflushesforcrblocksserved%:Avgglobalcachecrblockflushtime(ms):Avgglobalcachecurrentblockpintime(ms):Avgglobalcachecurrentblocksendtime(ms):Globalcachelogflushesforcurrentblocksserved%:Avgglobalcachecurrentblockflushtime(ms):0.1Avgglobalenqueuegettime(ms):Avgglobalcachecrblockreceivetime(ms):Avgglobalcachecurrentblockreceivetime(ms):Avgglobalcachecrblockbuildtime(ms):Avgglobalcachecrblocksendtime(ms):Globalcachelogflushesforcrblocksserved%:Avgglobalcachecrblockflushtime(ms):Avgglobalcachecurrentblockpintime(ms):Avgglobalcachecurrentblocksendtime(ms):Globalcachelogflushesforcurrentblocksserved%:Avgglobalcachecurrentblockflushtime(ms):0.00.00.00.43.0GlobalCacheandEnqueueServices-MessagingStatistics0.0Avgmessagesentqueuetime(ms):0.0Avgmessagesentqueuetimeonksxp(ms):Avgmessagereceivedqueuetime(ms):AvgGCSmessageprocesstime(ms):AvgGESmessageprocesstime(ms):%ofdirectsentmessages:%ofindirectsentmessages:Avgmessagesentqueuetimeonksxp(ms):Avgmessagereceivedqueuetime(ms):AvgGCSmessageprocesstime(ms):AvgGESmessageprocesstime(ms):%ofdirectsentmessages:%ofindirectsentmessages:%offlowcontrolledmessages:0.014.4077.048.56MainReportWaitEventsStatisticsSQLStatisticsInstanceActivityStatistics10StatsBufferPoolStatisticsAdvisoryStatisticsWaitStatisticsUndoStatisticsLatchStatisticsSegmentStatisticsDictionaryCacheStatisticsLibraryCacheStatisticsMemoryStatisticsStreamsStatisticsResourceLimitStatisticsinit.oraParametersWaitEventsStatisticsTimeModelStatisticsWaitClassWaitEventsBackgroundWaitEventsOperatingSystemStatisticsServiceStatisticsServiceWaitClassStatsBacktoTopTimeModelStatisticsTotaltimeindatabaseuser-calls(DBTime):663sStatisticsincludingtheword"background"measurebackgroundprocesstime,andsodonotcontributetotheDBtimestatisticOrderedby%orDBtimedesc,StatisticnameKBatfltflBBamsDBCPU514.5077.61sqlexecuteelapsedtime482.2772.74parsetimeelapsed3.760.57PL/SQLexecutionelapsedtime0.500.08hardparseelapsedtime0.340.05connectionmanagementcallelapsedtime0.080.01hardparse(sharingcriteria)elapsedtime0.000.00repeatedbindelapsedtime0.000.00PL/SQLcompilationelapsedtime0.000.00failedparseelapsedtime0.000.00DBtime662.97backgroundelapsedtime185.19backgroundcputime67.48此节显示了各种类型的数据库处理任务所占用的CPU时间。BacktoWaitEventsStatisticsBacktoTop

WaitClasss-secondcs-centisecond-100thofasecondms-millisecond-1000thofasecondus-microsecond-1000000thofasecondorderedbywaittimedesc,waitsdescUserI/O66,8370.00120211.94SystemI/O28,2950.009335.05Network1,571,4500.00660280.72Cluster210,5480.0029037.61Other81,78371.8228014.61Application333,1550.0016059.51Concurrency5.1820.04510.93Commit9190.00440.16Configuration25,42799.46104.54BacktoWaitEventsStatisticsBacktoTopWaitEventss-secondcs-centisecond-100thofasecondms-millisecond-1000thofasecondus-microsecond-1000000thofasecondorderedbywaittimedesc,waitsdesc(idleeventslast)EventWaits%TimeITotalWaitAvgwaitWaitsSQL*Netmoredatafromclient27,3190.006424.88logfileparallelwrite5,4970.004790.98dbfilesequentialread7,9000.003541.41dbfileparallelwrite4,8060.003470.86dbfilescatteredread10,3100.003131.84directpathwrite42,7240.003017.63reliablemessage3552.8218490.06SQL*Netbreak/resettoclient333,0840.0016059.50dbfileparallelread3,7320.001340.67gccurrentmultiblockreauest175,7100.0010031.39controlfilesequentialread15,9740.001012.85directpathreadtemp1,8730.00950.33gccrmultiblockreauest20,8770.00803.73logfilesync9190.00440.16gccrblockbusy5260.00360.09ena:FB-contention10,3840.00301.85DFSlockhandle3,5170.00310.63controlfileparallelwrite1,9460.00310.35gccurrentblock2-way4,1650.00200.74librarycachelock4320.00240.08

name-servicecallwait220.002760.00rowcachelock3,8940.00200.70gcslogflushsync1,25942.02210.22osthreadstartuo185.562890.00gccrblock2-way3,6710.00200.66gccurrentblockbusy1130.001120.02SQL*Netmessagetoclient1.544.1150.0010275.83gcbufferbusy156.671700.00gccrdiskread3,2720.00100.58directpathwritetemp1590.00150.03gccurrentgrantbusy8980.00110.16logfileswitchcompletion290.001170.01CGSwaitforIPCmsg48,73999.87008.71gccurrentgrant2-way1,1420.00000.20kjbdrmcvtqlmondrmquiesce:pingcompletion90.000190.00ena:US-contention5670.00000.10directpathread1380.00010.02ena:WF-contention140.00090.00ksxrpollremoteinstances13,29158.45002.37librarycachepin2110.00010.04gesglobalresourcedirectorytobefrozen9100.000100.00waitforscnack5830.00000.10logfilesequentialread360.00020.01undosegmentextension25,34299.79004.53rdbmsipcreply2790.00000.05ktfbtgex6100.000100.00ena:HW-contention440.00010.01gccrgrant2-way1580.00000.03ena:TX-indexcontention10.000340.00enq:CF-contention640.00010.01PXDeq:SignalACK3721.62010.01latchfree30.000100.00bufferbusywaits6250.16000.11KJC:Waitformsgsendstocomplete1540.00000.03logbufferspace110.00020.00enq:PS-contention460.00010.01enq:TM-contention700.00000.01IPCsendcompletionsync40100.00000.01PXDeq:reapcredit1544998100028logfilesinglewrite360.00000.01enq:TT-contention460.00000.01enq:TD-KTFdumpentries120.00010.00readbyothersession10.000120.00LGWRwaitforredocopy5400.00000.10PXDeqCredit:sendblkd175.88000.00enq:TA-contention140.00000.00latch:gesresourcehashlist440.00000.01enq:PI-contention80.00000.00writecompletewaits10.00020.00enq:DR-contention30.00000.00enq:MW-contention30.00000.00enq:TS-contention30.00000.00PXqreflatch150100.00000.03enq:MD-contention20.00000.00latch:KCLgcelementparentlatch110.00000.00enq:JS-jobrunlock-synchronize10.00010.00SQL*Netmoredatatoclient160.00000.00latch:cachebufferslruchain10.00000.00enq:UL-contention10.00000.00gccurrentsplit10.00000.00enq:AF-taskserialization10.00000.00latch:objectqueueheaderoperation30.00000.00latch:cachebufferschains10.00000.00latch:enqueuehashchains20.00000.00SQL*Netmessagefromclient1,544,1130.0012,6268275.83gcsremotemessage634,88498.649,20314113.41DIAGidlewait23,6280.004,6161954.22gesremotemessage149,59193.454,6123126.72StreamsAQ:qmnslaveidlewait1670.004,611276110.03StreamsAQ:qmncoordinatoridlewait35147.864,611131370.06StreamsAQ:waitingformessagesinthequeue488100.004,60594360.09virtualcircuitstatus157100.004,596292720.03PXIdleWait1,07297.112,58124070.19jobqslavewait14597.9342028960.03StreamsAQ:waitingfortimemanagementorcleanuptasks1100.002702697470.00PXDeq:ParseReply4040.00030.01PXDeq:ExecutionMsg12126.45000.02PXDeq:JoinACK3842.11010.01PXDeq:ExecuteReply3432.35000.01PXDeq:MsgFragment160.00000.00StreamsAQ:RACqmncoordinatoridlewait351100.00000.06classslavewait20.00000.00dbfilescatteredread等待事件是当SESSION等待multi-blockI/O时发生的，通过是由于fulltablescans或indexfastfullscans。发生过多读操作的Segments可以在“SegmentsbyPhysicalReads"和“SQLorderedbyReads"节中识别（在其它版本的报告中，可能是别的名称）。如果在OLTP应用中，不应该有过多的全扫描操作，而应使用选择性好的索引操作。DBfilesequentialread等待意味着发生顺序I/O读等待（通常是单块读取到连续的内存区域中），如果这个等待非常严重，应该使用上一段的方法确定执行读操作的热点SEGMENT，然后通过对大表进行分区以减少I/O量，或者优化执行计划（通过使用存储大纲或执行数据分析）以避免单块读操作引起的sequentialread等待。通过在批量应用中，DBfilesequentialread是很影响性能的事件，总是应当设法避免。LogFileParallelWrite事件是在等待LGWR进程将REDO记录从LOG缓冲区写到联机日志文件时发生的。虽然写操作可能是并发的，但LGWR需要等待最后的I/O写到磁盘上才能认为并行写的完成，因此等待时间依赖于OS完成所有请求的时间。如果这个等待比较严重，可以通过将LOG文件移到更快的磁盘上或者条带化磁盘（减少争用）而降低这个等待。 BufferBusyWaits事件是在一个SESSION需要访问BUFFERCACHE中的一个数据库块而又不能访问时发生的。缓冲区“busy”的两个原因是：1）另一个 SESSION正在将数据块读进BUFFERo2）另一个SESSION正在以排它模式占用着这块被请求的BUFFER。可以在“SegmentsbyBufferBusyWaits"一节中找 出发生这种等待的SEGMENT，然后通过使用reverse-keyindexes并对热表进行分区而减少这种等待事件。LogFileSync事件，当用户SESSION执行事务操作（COMMIT或ROLLBACK等）后，会通知LGWR进程将所需要的所有REDO信息从LOGBUFFER写到 LOG文件，在用户SESSION等待LGWR返回安全写入磁盘的通知时发生此等待。减少此等待的方法写LogFileParallelWrite事件的处理。 EnqueueWaits是串行访问本地资源的本锁，表明正在等待一个被其它 SESSION（一个或多个）以排它模式锁住的资源。减少这种等待的方法依赖于生 产等待的锁类型。导致Enqueue等待的主要锁类型有三种：TX（事务锁），TMD（ML锁）和ST（空间管理锁）。BacktoWaitEventsStatisticsBacktoTopBackgroundWaitEventsorderedbywaittimedesc,waitsdesc(idleeventslast)Event|Waits%TimeITotalWaitTime(s)Avgwait(ms)Waits—/txnlogfileparallelwrite5,4970.004790.98dbfileparallelwrite4,8060.003470.86eventsinwaitclassOther69,00283.2522012.33controlfilesequentialread9,3230.00711.67controlfileparallelwrite1,9460.00310.35osthreadstartup185.562890.00directpathread1380.00010.02dbfilesequentialread210.00050.00directpathwrite1380.00000.02logfilesequentialread360.00020.01gccrblock2-way960.00000.02gccurrentblock2-way780.00000.01logbufferspace110.00020.00rowcachelock590.00000.01logfilesinglewrite360.00000.01bufferbusywaits1510.66000.03gccurrentgrantbusy290.00000.01librarycachelock40.00010.00enq:TM-contention100.00000.00gccurrentgrant2-way80.00000.00gccrmultiblockrequest70.00000.00gccrgrant2-way50.00000.00rdbmsipcmessage97,28873.7750,19451617.38

gcsremotemessage634,88698.649,20314113.41DIAGidlewait23,6280.004,6161954.22pmontimer1,621100.004,61528470.29gesremotemessage149,59193.454,6123126.72StreamsAQ:qmnslaveidlewait1670.004,611276110.03StreamsAQ:qmncoordinatoridlewait35147.864,611131370.06smontimer2776.504,531163560.05StreamsAQ:waitingfortimemanagementorcleanuptasks1100.002702697470.00PXDeq:ParseReply4040.00030.01PXDeq:JoinACK3842.11010.01PXDeq:ExecuteReply3432.35000.01StreamsAQ:RACqmncoordinatoridlewait351100.00000.06BacktoWaitEventsStatisticsBacktoTopOperatingSystemStatisticsEOtlflNUMLCPUS0NUMVCPUS0AVGBUSYTIME101,442AVGIDLETIME371,241AVGIOWAITTIME5,460AVGSYSTIME25,795AVGUSERTIME75,510BUSYTIME812,644IDLETIME2,971,077IOWAITTIME44,794SYSTIME207,429USERTIME605,215LOAD0OSCPUWAITTIME854,100RSRCMGRCPUWAITTIME0PHYSICALMEMORYBYTES8,589,934,592NUMCPUS8NUMCPUCORES4NUMLCPUS：如果显示0,是因为没有设置LPARSNUMVCPUS:同上。AVGBUSYTIME：BUSYTIME/NUMCPUSAVGIDLETIME：IDLETIME/NUMCPUSAVGIOWAITTIME：IOWAITTIME/NUMCPUSAVGSYSTIME：SYSTIME/NUMCPUSAVGUSERTIME：USERTIME/NUMCPUSaroBUSYTIMEBUSYTIME：IDLETIME：IOWAITTIMESYSTIME：timeequivof%usr+%sysinsaroutputtimeequivof%idleinsartimeequivof%wioinsartimeequivof%sysinsarUSER_TIME： timeequivof%usrinsarLOAD： 未知OS_CPU_WAIT_TIME: supposedlytimewaitingonrunqueuesRSRC_MGR_CPU_WAIT_TIME:timewaitedcozofresourcemanagerPHYSICAL_MEMORY_BYTES: totalmemoryinusesupposedlyNUM_CPUS: numberofCPUsreportedbyOSNUM_CPU_CORES: numberofCPUsocketsonmotherboard总的elapsedtime也可以用以公式计算：BUSY_TIME+IDLE_TIME+IOWAITTIME或：SYS_TIME+USER_TIME+IDLE_TIME+IOWAIT_TIME(因为BUSY_TIME=SYS_TIME+USER_TIME)BacktoWaitEventsStatisticsBacktoTopServiceStatistics•orderedbyDBTimeICCI608.10496.60315,84916,550,972SYS$USERS54.7017.806,53958,929ICCIXDB0.000.0000SYS$BACKGROUND0.000.0028238,990BacktoWaitEventsStatisticsBacktoTopServiceWaitClassStatsWaitClassinfoforservicesintheServiceStatisticssection.TotalWaitsandTimeWaiteddisplayedforthefollowingwaitclasses:UserI/O,Concurrency,Administrative,NetworkTimeWaited(WtTime)incentisecond(100thofasecond)ServiceNameUserI/OTotalWtsUserI/OWtTimeConcurcyTotalWtsConcurcyWtTimeAdminTotalWtsAdminTWteNetworkTotalWtsNetworkWtTimeICCI59826864046213380015640596552SYS$USERS65673238231110073233SYS$BACKGROUND4431153301680000BacktoWaitEventsStatisticsBacktoTopSQLStatisticsSQLorderedbyElapsedTimeSQLorderedbyCPUTimeSQLorderedbyGetsSQLorderedbyReadsSQLorderedbyExecutionsSQLorderedbyParseCallsSQLorderedbySharableMemorySQLorderedbyVersionCountSQLorderedbyClusterWaitTimeCompleteListofSQLText本节按各种资源分别列出对资源消耗最严重的SQL语句，并显示它们所占统计期内全部资源的比例，这给出我们调优指南。例如在一个系统中，CPU资源是系统性能瓶颈所在，那么优化buffergets最多的SQL语句将获得最大效果。在一个I/O等待是最严重事件的系统中，调优的目标应该是physicalIOs最多的SQL语句。在STATSPACK报告中，没有完整的SQL语句，可使用报告中的HashValue通过下面语句从数据库中查到：selectsql_textfromstats$sqltextwherehash_value=&hash_valueorderbypiece;BacktoTopSQLorderedbyElapsedTimeResourcesreportedforPL/SQLcodeincludestheresourcesusedbyallSQLstatementscalledbythecode.%TotalDBTimeistheElapsedTimeoftheSQLstatementdividedintotheTotalDatabaseTimemultipliedby100ElapsedTime(s)CPUTime(s)ExecutionLOElapperExec(s)%TotalDBTimeSQLIdSQLModuleSQLText9357193.5014.10d8z0u8hgj8xdycuidmain@HPGICCI1(TNSV1-V3)insertintoCUIDselectCUID...7675172,3290.0011.524vja2k2gdtyupload_fnsact@HPGICCI1(TNSV1-V3)insertintoICCICCSvalues(■...5842158.048.75569r5k05drsj7cumimain@HPGICCI1(TNSV1-V3)insertintoCUMIselectCUSV...5142150.937.68ackxqhnktxnbccusmmain@HPGICCI1(TNSV1-V3)insertintoCUSMselectCUSM...3836166,0690.005.677,fromco...353135.005.286z06gcfw39pkdSQL*PlusSELECTF.TABLESPACE_NAME,TO...2323172,3290.003.461dm3bq36vu3g8load_fnsact@HPGICCI1(TNSV1-V3)insertintoiccifnsactvalues...151152.982.25djs2w2f17nw2zDECLAREjobBINARYINTEGER■=...1414172,9830.002.167wwv1ybs9zguzload_fnsact@HPGICCI1(TNSV1-V3)updateICCIFNSACTsetBORMAD...1313172,3370.002.00gmn2w09rdxn14load_oldnewact@HPGICCI1(TNSV1-V3)insertintoOLDNEWACTvalues...1313166,0510.001.89chjmy0dxf9mbjicci_migact@HPGICCI1(TNSV1-V3)insertintoICCICCSvalues(■...10■119.701.460yv9t4qb1zb2bcuidmain@HPGICCI1(TNSV1-V3)selectCUID_CUST_NO,CUIDID...10851.911.441cra]pb7J5tyzINSERTINTOSTATS$SGA_TARGET_A...88172,3290.001.2538apjgr0p55nsload_fnsact@HPGICCI1(TNSV1-V3)updateICCICCSsetCCSMAXOVER...88172,9830.001.165c4qu2zmj3guxload_fnsact@HPGICCI1(TNSV1-V3)select*fromICCIPRODCODEwh...记录了执行总和时间的TOPSQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间ElapsedTime=CPUTime+WaitTime)oElapsedTime(S):SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒。ElapsedTime=CPUTime+WaitTimeCPUTime(s):为SQL语句执行时CPU占用时间总时长，此时间会小于等于ElapsedTime时间。单位时间为秒。Executions:SQL语句在监控范围内的执行次数总计。ElapperExec(s):执行一次SQL的平均时间。单位时间为秒。%TotalDBTime:为SQL的ElapsedTime时间占数据库总时间的百分比。SQLID:SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQLID的地方。SQLModule:显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。SQLText:简单的sql提示，详细的需要点击SQLID。BacktoSQLStatisticsBacktoTopSQLorderedbyCPUTimeResourcesreportedforPL/SQLcodeincludestheresourcesusedbyallSQLstatementscalledbythecode.%TotalDBTimeistheElapsedTimeoftheSQLstatementdividedintotheTotalDatabaseTimemultipliedby100CPUTime(s)ElapsedTime1(s)CPUperExec(s)%TotalDBTimeSQLIdSQLModuleSQLText7576172,3290.0011.524vja2k2gdyupload_fnsact@HPGICCI1(TNSV1-V3)insertintoICCICCSvalues(:…5793157.3114.10d8z0u8hgj8xdycuidmain@HPGICCI1(TNSV1-V3)insertintoCUIDselectCUID...4251142.437.68ackxqhnktxnbccusmmain@HPGICCI1(TNSV1-V3)insertintoCUSMselectCUSM...4258142.018.75569r5k05dfsj7cumimain@HPGICCI1(TNSV1-V3)insertintoCUMIselectCUSV...3638166,0690.005.677,fromco...2323172,3290.003.461dm3bq36vu3g8load_fnsact@HPGICCI1(TNSV1-V3)insertintoiccifnsactvalues...1414172,9830.002.16〔7wwv1vbs9zauloadfnsact@HPGICCI1updateICCIFNSACTset

2—(TNSV1-V3)BORMAD...1313172,3370.002.00gmn2w09rdxn14load_oldnewact@HPGICCI1(TNSV1-V3)insertintoOLDNEWACTvalues...1313166,0510.001.89chjmy0dxf9mbjicci_migact@HPGICCI1(tNSV1-V3)insertintoICCICCSvalues(■...111552.232.25|djs2w2f17nw2zDECLAREjobBINARYINTEGER■=...88172,3290.001.2538apjgf0p55nsload_fnsact@HPGICCI1(TNSV1-V3)updateICCICCSsetCCSMAXOVER...81051.601.441cra]pb7J5tyzINSERTINTOSTATS$SGA_TARGET_A...88172,9830.001.165c4qu2zm]3guxload_fnsact@HPGICCI1(TNSV1-V3)select*fromICCIPRODCODEwh...41013.541.46cuidmain@HPGICCI1(TNSV1-V3)selectCUID_CUST_NO,CUIDID...33513.135.286z06gcfw39pkdSQL*PlusSELECTF.TABLESPACE_NAME,TO...记录了执行占CPU时间总和时间最长的TOPSQL（请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间）。BacktoSQLStatisticsBacktoTopSQLorderedbyGetsResourcesreportedforPL/SQLcodeincludestheresourcesusedbyallSQLstatementscalledbythecode.TotalBufferGets:16,648,792CapturedSQLaccountfor97.9%ofTotalBufferGetsExecutionsGetsperExec%TotalCPUTime(s)ElapsedTime(s)SQLIdSQLModuleISQLText13,305,363172,32919.1819.8574.5776.414vja2k2gdyupload_fnsact@HPGICCI1(TNSV1-V3)insertintoICCICCSvalues(:...2,064,41412,064,414.0012.4057.3193.50d8z0u8hgj8xdycuidmain@HPGICCI1(TNSV1-V3)insertintoCUIDselectCUID...1,826,869166,06911.0010.9735.8437.607,fromco...1,427,648172,3378.288.5812.9713.29gmn2w09rdxn14load_oldnewact@HPGICCI1(TNSV1-V3)insertintoOLDNEWACTvalues...1,278,667172,3297.427.6822.8522.941dm3bq36vu3g8load_fnsact@HPGICCI1(TNSV1-V3)insertintoiccifnsactvalues...1,216,36711,216,367.007.3142.4350.93ackxqhnktxnbccusmmain@HPGICCI1(TNSV1-V3)insertintoCUSMselectCUSM...记录了执行占总buffergets（逻辑IO）的TOPSQL（请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets）。

BacktoSQLStatisticsBacktoTopSQLorderedbyReadsTotalDiskReads:322,678CapturedSQLaccountfor66.1%ofTotalPhysicReadsExecutionsReadsperExec%TotalCPUTime(s)ElapsedTsmeSQLIdSQLModuleSQLText66,286166,286.0020.5457.3193.50d8z0u8hgj8xdycuidmain@HPGICCI1(TNSV1-V3)insertintoCUIDselectCUID...50,646150,646.0015.703.549.700yv9t4qb1zb2bcuidmain@HPGICCI1(TNSV1-V3)selectCUID_CUST_NO,CUIDID...24,507124,507.007.5942.0158.04569r5k05drsj7cumimain@HPGICCI1(TNSV1-V3)insertintoCUMIselectCUSV...21,893121,893.006.7842.4350.93ackxqhnktxnbccusmmain@HPGICCI1(TNSV1-V3)insertintoCUSMselectCUSM...19,761119,761.004a7nh7j8zmfrzwcumimain@HPGICCI1(TNSV1-V3)selectCUSV_CUST_NOfromCUMI...记录了执行占总磁盘物理读（物理IO）的TOPSQL（请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读）。BacktoSQLStatisticsBacktoTopSQLorderedbyExecutionsTotalExecutions:1,675,112CapturedSQLaccountfor99.8%ofTotalExecution171RowsProcessedRowsperExecCPUperExeElapperExeSQLIdSQLModuleSQLText172,983172,3291.000.000.005c4qu2zml3guxload_fnsact@HPGICCI1(TNSV1-V3)select*fromICCIPRODCODEwh...172,983172,3291.000.000.007ufufi，1ybs9zguzload_fnsact@HPGICCI1(TNSV1-V3)updateICCIFNSACTsetBORMAD...172,337172,3371.000.000.00/vmnOiMnQrrlvnlload_oldnewact@HPGICCI1(TNSV1-V3)insertintoOLDNEWACTvalues...4172,329172,3291.000.000.001dm3bq36vu3gload_fnsact@HPGICCI1(TNSV1-V3)insertintoiccifnsactvalues...8172,329172,3291.000.000.0038apjgr0p55nsload_fnsact@HPGICCI1(TNSV1-V3)updateICCICCSsetCCSMAXOVER..w0a|Jjy1 IO172,3296,2860.040.000.004vja2k2gdtyupload_fnsact@HPGICCI1(TNSV1-V3)insertintoICCICCSvalues(:...166,069166,0691.000.000.007,fromco...记录了按照SQL的执行次数排序的TOPSQL。该排序可以看出监控范围内的SQL执行次数。BacktoSQLStatisticsBacktoTopSQLorderedbyParseCallsTotalParseCalls:182,780CapturedSQLaccountfor99.0%ofTotalIParseExecutions%TotalSQLIdSQLSQLText166,069166,06990.867,fromco...630463043452ym6hhaq30r73selecttype#blocksextents2,4372,4381.33bsa0witftg3uwselectfile#fromfile$where...1,5681,5680.869qgtwh66xg6nzupdateseg$settype#=:4,bloc...1.5541,5540.85aq4js2gkfjru8uodatetsq$setblocks=:3,max...4444440.24104pd9mm3fh9pselectblocks,maxblocks,gran...4214210.23350f5yrnnmshslocktablesys.monmods$inex...4214210.23g00c]285]mgswupdatesys.monmods$setinser...86860.053m8smr0v7v1m6INSERTINTOsys.wri$advmessa...81810.04f80h0xb1qvbskSELECTsys.wri$advseqmsggro...记录了SQL的软解析次数的TOPSQL。说到软解析(softprase)和硬解析(hardprase)，就不能不说一下Oracle对sql的处理过程。B