OracleAWR报告分析实例讲解

1、WORKLOADREPOSITORYreportforDBNameDBIdInstanceInstnumReleaseRACHostICCI1314098396ICCI1.0YESHPGICCI11SnapIdSnapTimeSessionsCursors/SessionBeginSnap:267825-Dec-0814:04:50I_241.5EndSnap:268025-Dec-0815:23:372675Elapsed:78.79(mins)DBTime:11.05(mins)Elapsed 表示整个 AWR 报表统计的时间长度DBTime 是记录在服务器花在数据库运算

2、（非后台进程）和等待（非空闲等待）上的时间DBTime=cputime+waittime（不包含空闲等待）（非后台进程）DBTime 不包括 Oracle 后台进程消耗的时间。 如果 DBTime 远远小于 Elapsed 时间，说明数据库比较空闲。上述报表中Snapshot 时间问B 约为 79 分钟，cpu 就公有 8*79=632 分钟。DBTime 为 11.05分钟，则：cpu 花费了 11.05 分钟在处理 oracle 非空闲等待和运算上（比如逻辑读），也就是说 cpu 有 11.05/632=0.017%花费在处理 oracle 的操作上。从 awrreport 的 Elaps

3、edtime 和 DBTime 就能大概了解 db 的负载，计算公式可参考为：cpu 负载二 DBTime/（cpu 数*Elapsed）*100%在 79 分钟里（其间收集了 3 次快照数据），数据库耗时 11 分钟，RDA 数据中显示系统有 8 个逻辑 CPU（4 个物理 CPU）,平均每个 CPU 耗时 1.4 分钟，CPU 利用率只有大约 2%（1.4/79）。说明系统压力非常小。可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代

4、表性能问题的时间段。ReportSummaryCacheSizesBeginEndBufferCache:3,344M3,344MStdBlockSize:|8KSharedPoolSize:704M704M LogBuffer:II14,352K显示 SGA 中每个区域的大小（在 AMM 改变它们之后），可用来与初始参数值比较。sharedpool 主要包括 librarycache 和 dictionarycache。 librarycache 用来存储最近解析（或编译）后 SQL、PL/SQL 和 Javaclassed。librarycache 用来存储最近弓 I 用的数据字典。发生在

5、 librarycache 或 dictionarycache 的 cachemiss 代价要比发生在 buffercache 的代价高得多。因此 sharedpool 的设置要确保最近使用的数据都能被 cacheLoadProfilePerSecondPerTransactionDBTime(s)2.40.0Redosize:91880572775,912.72Logicalreads:3,521.772,974.06Blockchanges:1,535.221,817.95Physicalreads:68.2657.64Physicalwrites:362.59306.20Usercall

6、s:326.69275.88Parses:38.6632.65Hardparses:0.030.03Sorts:0.610.51Logons:0.010.01Executes:354.34299.23Transactions:1.18%BlockschangedperRead:51.62 RecursiveCall%:51.72Rollbackpertransaction%:85.49 RowsperSort:#显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，

7、然而 Logons 大于每秒 12个、Hardparse 以于每秒 100、全部 parses 超过每秒 300 表明可能有争用问题。DBTime（s）:每秒内用于 DB 处理的时间，其他时间为等待时间Redosize每秒/每事务产生的 redo 大小（单位字节），可标志数据库任务的繁重程序。其中 PerSecon 球示每秒中产生的 redo 的字节数，PerTransaction示每个事务产生的 redo 的字节数，可以通过后者可以看到事务的大小，协助判断是否 commit 次数太多。例如 persecond 很大，而 pertransaction 很小，说明 commit 次数太多。通常在

8、很繁忙的系统中日志生成量可能达到上百 k,甚至几百k。Logicalreads：每秒/每事务逻辑读的块数（我们可以这样认为，block 在内存中，我们每一次读一块内存，就相当于一次逻辑读），单位为块，在良好的 OLTP 环境中，Logicalreads/Executes会超过 50,一股只有 10 左右，如果该指标较大，表示语句可能不够优化，需要具体分析，在该示例中，3,521.77/354.34 那么在 OLAP 中呢？Blockchanges每秒/每事务修改的块数，即每秒中多少个块发生变化Physicalreads 每秒/每事务物理读的块数，即每秒数据库从磁盘读取的块个数Physicalw

9、rites：每秒/每事务物理写的块数，即每秒有多少个块接受了数据库写入数据。Usercalls：每秒/每事务用户 call 次数 Usercalls/Executes 基本代表每个语句的请求次数，Executes 越接近 Usercalls 越好。Parses每秒的 SQL 语句解析的次数，超过 300 即需要关注，可以考虑调整参数session_cursor_cache改善解析次数过高的现象。Hardparses 其中硬解析的次数，如果硬解析次数太高，说明 SQL 重用率不高。例如超过 100,基本都是由于不使用 bindvar 所导致的，导致 cpu 使用率的问题，极有使得性能急剧下降。S

10、orts：每秒/每事务的排序次数Logons：每秒/每事务登录的次数Executes 每秒/每事务 SQL 执行次数，包括用户执行的 sql 语句与系统执行的 sql 语句，表示一个系统 sql 的繁忙程度。Transactions 每秒产生的事物个数，反映数据库负载程度，不同的系统，略有差异，在典型的交易系统中，事务较多，而网站系统，可能 select 查询较多。BlockschangedperRead 表示逻辑读用于修改数据块的比例RecursiveCall:递归调用占所有操作的比率Rollbackpertransaction：每事务的回滚率Rollbacks：表示数据库中事务的回退率，如

11、果不是因为业务本身的原因，通常应该小于 10%为好，回退是一个很消耗资源的操作。RowsperSort 每次排序的行数注：Oracle 的硬解析和软解析提至 U 软解析(softparse 和硬解析(hardparse)就不能不说一下 Oracle 对 sql 的处理过程。当你发出一条 sql 语句交付 Oracle,在执行和获取结果前，Oracle 对此 sql 将进行几个步骤的处理过程：1、语法检查(syntaxcheck)检查此 sql 的拼写是否语法。2、语义检查(semanticcheck)诸如检查 sql 语句中的访问对象是否存在及该用户是否具备相应的权限。3、对 sql 语句进行

12、解析(parse)利用内部算法对 sql 进行解析， 生成解析树(parsetree 及执行计划(executionplan)。4、执行 sql,返回结果(executeandreturn)其中，软、硬解析就发生在第三个过程里。Oracle 利用内部的 hash 算法来取得该 sql 的 hash 值， 然后在 librarycache 里查找是否存在该 hash假设存在，则将此 sql 与 cache 中的进行比较；假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。诚然，如果上面的 2 个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行

13、计划的动作。这个过程就叫硬解析。创建解析树、生成执行计划对于 sql 的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。InstanceEfficiencyPercentages(Target100%)BufferNowait%:100.00RedoNoWait%:100.00BufferHit%:98.72 In-memorySort%:99.86LibraryHit%:99.97 SoftParse%:99.92ExecutetoParse%:89.09 LatchHit%:99.99ParseCPUtoParseElapsd%:7.99%Non-ParseCPU:II

14、99.95本节包含了 Oracle 关键指标的内存命中率及其它数据库实例操作的效率。其中BufferHitRatio 也称 CacheHitRatio,LibraryHitratio 也称 LibraryCacheHitratioo 同LoadPro 巾 le 一节相同， 这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的 DSS 环境，20%的 BufferHitRatio 是可以接受的，而这个值又 t 于一个 OLTP 系统是完全不能接受的。根据 Oracle 的经验，对于 OLTPT系统,BufferHitRatio 理想应该在 90%以上

15、。BufferNowait%表示在数据缓冲区中获取的 buffer 时， 未进行等待的比率， 越高越好。bufferhit%表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的 OLTP 系统，命中率通常在 95以上，如果此值低于 80%,应该给数据库分配更多的内存，考虑加大 db_cache_size 在数据仓库 OLAP 环境中， 数据缓冲命中率不是一个重要的指标， 因为 OLAP 数据库主要是物理读，甚至是直接读，该命中率不可能高。RedoNoWai%t 表示在 LOG 缓冲区获得 BUFFER 的未等待比例。如果太低（可参考90%阀值），考虑增加

16、LOGBUFFER0libraryhit%表示 Oracle从 LibraryCache中检索到一个解析过的 SQL或 PL/SQL语句的比率，当应用程序调用 SQL 或存储过程时，Oracle 检查 LibraryCache 确定是否存在解析过的版本，如果存在，Oracle 立即执行语句；如果不存在，Oracle 解析此语句，并在 LibraryCache 中为它分配共享 SQL 区。低的 libraryhitratio 会导致过多的解析，增加CPU 消耗， 降低性能。 Sql 语句在库缓冲中能否找到相应的解析计划， 如果 libraryhitratio低于 90%,可能需要调大 share

17、dpool 区，或检查是否有硬编码现象。LatchHit%:Latch 是一种保护内存结构的锁，可以认为是 SERVER 进程获取访问内存数据结构的许可，表示内部结构维护锁命中率。要确保 LatchHit99%,否则意味着 SharedPoollatch 争用，可能由于未共享的 SQL,或者 LibraryCache 太小，可使用绑定变更或调大 SharedPool 解决。ParseCPUtoParseElaps 业示解析实际运行时间/（解析实际运行时间+解析中等待资源时间），越高越好。在实际繁忙的系统中，该值可能因为等待资源而不会太局0Non-ParseCPU:SQL 实际运行时间/（SQL

18、 实际运行时间+SQL 解析时间），太低表示解析消耗时间过多。说明解析时间所占比率过高，需要考虑提高 sql 语句重用性。ExecutetoParse 是语句执行与分析的比例，表示 sql 语句解析后被重复执行的命中率，计算公式=100*（1-Parses/Executions，如果该值偏小，说明分析（硬分析和软分析） 的比例较大， 快速分析较少， 根据实际情况， 可以考虑调整 session_cached_cursor参数，有些报告中这个值是负的，看上去很奇怪，事实上这表示一个问题，sql 如果被ageout 的话就可能出现这种情况，也就是 sql 老化，执行 altersystemflus

19、hshared_pool如果要 SQL 重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。SoftParse%SQL 语句软解析占整个分析的命中率，如果低于 95,需检查是否有硬编码现象，如果低于 80,说明 sql 语句基本没有重用性=soft/（soft+hard）In-memorySort:在内存中排序的比率，即有多少排序在内存中进行的，如果过低说明有大量的排序在临时表空间中进行，性能肯定不好，考虑调大 PGA 参数,sort_area_sizeSoftParse 软解析的百分比（softs/softs+hard,近似当作 sql 在共享区的命中率，太低则需要调整应

20、用使用绑定变量。SharedPoolStatisticsBeginEndMemoryUsage%:47.1947.50%SQLwithexecutions1:88.4879.81%MemoryforSQLw/exec1:79.9973.52MemoryUsage%:表示共享池内存使用率， 对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在 75%-90%问，如果太小，说明 SharedPool 有浪费，而如果高于 90,说明共享池中有争用，内存不足。SQLwithexecutions:执行次数大于 1 的 sql 比率，如果此值太小的话要结合 Parse,看看是不是硬编码现象，

21、说明需要在应用中更多使用绑定变量，避免过多 SQL 解析。MemoryforSQLw/exec1:执行次数大于 1 的 SQL 消耗内存的占比。Top5TimedEventsEventWaitsTime(s)AvgWait(ms)%TotalCallTimeWaitClassCPUtime51577.6SQL*Netmoredatafromclient27,3196429.7 Networklogfileparallelwrite5,497匚4797.1 SystemI/Odbfilesequentialread7,9003545.3 UserI/Odbfileparallelwrite4,8

22、0634715.1SystemI/O这是报告概要的最后一节， 显示了系统中最严重的 5 个等待， 按所占等待时间的比例倒序列示。当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。例如如 果 bufferbusywait 是 较 严 重 的 等 待 事 件 ， 我 们 应 当 继 续 研 究 报 告 中 BufferWait 和File/TablespaceIO 区的内容，识别哪些文件导致了问题。如果最严重的等待事件是 I/O 事件，我们应当研究按物理读排序的 SQL语句区以识别哪些语句在执行大量I/O,并研究Tablespace和I/O区观察较慢响应时间的文件。如

23、果有较高的 LATCH 等待，就需要察看详细的 LATCH 统计识别哪些 LATCH 产生的问题。在这里，10gfileparallelwrite 是相对比较多的等待，占用了 7%的 CPU 时间。通常，在没有问题的数据库中，CPUtime 总是列在第一个。更多的等待事件，参见本报告的 WaitEvents 一节。GlobalCacheLoadProfile11PerSecondPerTransactionGlobalCacheblocksreceived:4.163.51GlobalCacheblocksserved:5.975.04GCS/GESmessagesreceived:408.4

24、7344.95GCS/GESmessagessent:258.03217.90DBWRFusionwrites:0.050.05EstdInterconnecttraffic(KB)211.16GlobalCacheEfficiencyPercentages(Targetlocal+remote100%)Bufferaccess-localcache%:98.60Bufferaccess-remotecache%:0.12Bufferaccess-disk%:1.28GlobalCacheandEnqueueServices-WorkloadCharacteristicsAvgglobalen

25、queuegettime(ms):0.1Avgglobalcachecrblockreceivetime(ms):1.1Avgglobalcachecurrentblockreceivetime(ms):0.8Avgglobalcachecrblockbuildtime(ms):0.0Avgglobalcachecrblocksendtime(ms):0.0Globalcachelogflushesforcrblocksserved%:3.5Avgglobalcachecrblockflushtime(ms):3.9Avgglobalcachecurrentblockpintime(ms):0

26、.0Avgglobalcachecurrentblocksendtime(ms):0.0Globalcachelogflushesforcurrentblocksserved%:0.4Avgglobalcachecurrentblockflushtime(ms):3.0GlobalCacheandEnqueueServices-MessagingStatisticsAvgmessagesentqueuetime(ms):0.0Avgmessagesentqueuetimeonksxp(ms):0.3Avgmessagereceivedqueuetime(ms):0.5AvgGCSmessage

27、processtime(ms):0.0AvgGESmessageprocesstime(ms):0.0%ofdirectsentmessages:14.40%ofindirectsentmessages:77.04%offlowcontrolledmessages:8.56MainReportWaitEventsStatisticsSQLStatisticsInstanceActivityStatisticsIOStatsBufferPoolStatisticsAdvisoryStatisticsWaitStatisticsUndoStatisticsLatchStatisticsSegmen

28、tStatisticsDictionaryCacheStatisticsLLibraryCacheStatisticsMemoryStatisticsStreamsStatisticsResourceLimitStatisticsinit.oraParametersWaitEventsStatisticsTimeModelStatisticsWaitClassWaitEventsBBackgroundWaitEventsOperatingSystemStatisticsServiceStatisticsServiceWaitClassStatsBacktoTopTimeModelStatist

29、icsTotaltimeindatabaseuser-calls(DBTime):663sStatisticsincludingthewordbackgroundmeasurebackgroundprocesstime,andsodonotcontributetotheDBtimestatisticOrderedby%orDBtimedesc,StatisticnameStatisticNameTime(s)%ofDBTimeDBCPU514.5077.61sqlexecuteelapsedtime482.2772.74parsetimeelapsed3.760.57PL/SQLexecuti

30、onelapsedtime0.500.08hardparseelapsedtime0.340.05connectionmanagementcallelapsedtime0.080.01hardparse(sharingcriteria)elapsedtime0.000.00repeatedbindelapsedtime0.000.00PL/SQLcompilationelapsedtime0.000.00failedparseelapsedtime0.000.00DBtime662.97backgroundelapsedtime185.19backgroundcputime67.48Backt

31、oWaitEventsStatisticsBacktoTop此节显示了各种类型的数据库处理任务所占用的CPU 时间WaitClasss-secondcs-centisecond-100thofasecond.ms-millisecond-1000thofasecondus-microsecond-1000000thofasecondorderedbywaittimedesc,waitsdescWaitClassWaits%Time-outsTotalWaitTime(s)Avgwait(ms)Waits/txnUserI/O66,8370.00120匚211.94SystemI/O28,295

32、0.00I9335.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-1000tho

33、faseconduus-microsecond-1000000thofasecondorderedbywaittimedesc,waitsdesc(idleeventslast)EventWaits%Time-outsTotalWaitTime(s)Avgwait(ms)Waits/txnSQL*Netmoredatafromclient27,3190.006424.88logfileparallelwrite5,4970.004790.98dbfilesequentialread7,9000.003541.41dbfileparallelwrite4,8060003470.86dbfiles

34、catteredread10,3100.003131.84directpathwrite42,7240.003017.63reliablemessage3552.8218490.06SQL*Netbreak/resettoclient333,0840.0016059.50dbfileparallelread3,7320.001340.67gccurrentmultiblockrequest175,7100.0010031.39controlfilesequentialread15,9740.001012.85directpathreadtemp1,8730.00950.33gccrmultib

35、lockrequest20,8770.00803.73logfilesync9190.00440.16gccrblockbusy5260.00360.09enq:FB-contention10,3840.00301.85DFSlockhandle3,5170.00310.63controlfileparallelwrite1,9460.00310.35gccurrentblock2-way4,1650.00200.74librarycachelock4320.00240.08name-servicecallwait220.002760.001rowcachelock3,8940.00200.7

36、0gcslogflushsync1,25942.02210.22osthreadstartup185.562890.00gccrblock2-way3,6710.00200.66gccurrentblockbusy1130.0011210.02SQL*Netmessagetoclient1,544,1150.0010275.83gcbufferbusy156.671700.00gccrdiskread3,2720.00100.58directpathwritetemp1590.00150.03gccurrentgrantbusy8980.00110.16logfileswitchcomplet

37、ion290.001170.01CGSwaitforIPCmsg48,73999.87008.71gccurrentgrant2-way1,1420.00000.20kjbdrmcvtqlmondrmquiesce:pingcompletion90.000190.00enq:US-contention5670.00000.10directpathread1380.00010.02enq:WF-contention140.00090.00ksxrpollremoteinstances13,29158.45002.37librarycachepin2110.00010.04gesglobalres

38、ourcedirectorytobefrozen9100.000100.00waitforscnack5830.00000.10logfilesequentialread360.00020.01undosegmentextension25,34299.79004.53rdbmsipcreply2790.00000.05ktfbtgex6100.000100.00enq:HW-contention440.00010.01gccrgrant2-way1580.00000.03enq:TX-indexcontention10.000340.00enq:CF-contention640.00010.0

39、1PXDeq:SignalACK3721.62010.01latchfree30.000100.00bufferbusywaits6250.16000.11KJC:Waitformsgsendstocomplete1540.00000.03logbufferspace110.00020.00enq:PS-contention460.00010.01enq:TM-contention700.00000.01IPCsendcompletionsync40100.00000.01PXDeq:reapcredit1,54499.81000.28logfilesinglewrite360.00000.0

40、1enq: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.

41、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.00g

42、ccurrentsplit10.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.22gesr

43、emotemessage149,59193.454,6123126.72StreamsAQ:qmnslaveidlewait1670.004,611276110.03StreamsAQ:qmncoordinatoridlewait35147.864,611131370.06StreamsAQ:waitingformessagesinthequeue488100.004,60594360.09virtualcircuitstatus157100.004,596292720.03PXIdleWait1,07297.112,58124070.19jobqslavewait14597.93420289

44、60.03StreamsAQ:waitingfortimemanagementorcleanuptasks1100.002702697470.00PXDeq:ParseReply4040.00030.01PXDeq:ExecutionMsg12126.45000.02PXDeq:JoinACK3842.11010.01PXDeq:ExecuteReply3432.35000.01PXDeq:MsgFragment160.00000.00StreamsAQ:RACqmncoordinatoridlewait351100.00000.06classslavewait20.00000.00dbfil

45、escatteredreacftH 寺事件是当 SESSION 等待 multi-blockI/O 时发生的，通过是由于 fulltablescans 或 indexfastfullscans 发生过多读操作的 Segments 可以在SegmentsbyPhysicalReadsffi”“SQLorderedbyRead 前中识另（在其它版本的报告中，可能是别的名称）。如果在 OLTP 应用中，不应该有过多的全扫描操作，而应使用选择性好的索引操作。DBfilesequentialread 等待意味着发生顺序 I/O 读等待（通常是单块读取到连续的内存区域中），如果这个等待非常严重，应该使用上

46、一段的方法确定执行读操作的热点SEGMENT,然后通过对大表进行分区以减少 I/O 量，或者优化执行计划（通过使用存储大纲或执行数据分析）以避免单块读操作引起的 sequentialread 等待。通过在批量应用中，DBfilesequentialread 是很影响性能的事件，总是应当设法避免。LogFileParallelWrite 事件是在等待 LGWR 进程将 REDO 记录从 LOG 缓冲区写到联机日志文件时发生的。虽然写操作可能是并发的，但 LGWR 需要等待最后的 I/O 写到磁盘上才能认为并行写的完成，因此等待时间依赖于 OS 完成所有请求的时间。如果这个等待比较严重，可以通过将

47、 LOG 文件移到更快的磁盘上或者条带化磁盘（减少争用）而降低这个等待。BufferBusyWa 人事件是在一个 SESSION 需要访问 BUFFERCACHE 中的一个数据库块而又不能访问时发生的。缓冲区“busy”的两个原因是：1）另一个SESSION 正在将数据块读进 BUFFERo2） 另一个 SESSION 正在以排它模式占用着这块被请求的 BUFFERo 可以在“SegmentsbyBufferBusyWa 让 S一节中找出发生这种等待的 SEGMENT,然后通过使用 reverse-keyindexes 并对热表进行分区而减少这种等待事件。LogFileSync 事件，当用户

48、SESSION 执行事务操作（COMMIT 或 ROLLBACK 等）后，会通知 LGWR 进程将所需要的所有 REDO 信息从 LOGBUFFER 写到 LOG 文件，在用户 SESSION 等待 LGWR 返回安全写入磁盘的通知时发生此等待。 减少此等待的方法写 LogFileParallelWrite 事件的处理。EnqueueWaits 是用行访问本地资源的本锁，表明正在等待一个被其它SESSION（一个或多个）以排它模式锁住的资源。减少这种等待的方法依赖于生产等待的锁类型。导致 Enqueue 等待的主要锁类型有三种：TX（事务锁），TMD（ML 锁）和 ST（空间管理锁）。Back

49、toWaitEventsStatisticsBacktoTopBackgroundWaitEventsorderedbywaittimedesc,waitsdesc(idleeventslast)EventWaits%Time-outsTotalWaitTime(s)Avgwait(ms)Waits/txnlogfileparallelwrite5,4970.004790.98dbfileparallelwrite4,8060.003470.86eventsinwaitclassOther69,00283.2522012.33controlfilesequentialread9,3230.00

50、711.67controlfileparallelwrite1,9460.00310.35osthreadstartup185.562890.00directpathread1380.00010.02dbfilesequentialread210.00050.00directpathwrite1380.00000.02logfilesequentialread360.00020.01gccrblock2-way960.00000.02gccurrentblock2-way780.00000.01logbufferspace110.00020.00rowcachelock590.00000.01

51、logfilesinglewrite360.00000.01bufferbusywaits1510.66000.03gccurrentgrantbusy|_290.00000.01librarycachelock40.00010.00enq:TM-contention100.00000.00gccurrentgrant2-way80.00000.00gccrmultiblockrequest70.00000.00gccrgrant2-way50.00000.00rdbmsipcmessage97,28873.7750,19451617.38gcsremotemessage634,88698.6

52、49,20314113.41DIAGidlewait23E280.004,6161954.22pmontimer1,621100.004,61528470.29gesremotemessage149,59193.454,61231126.72StreamsAQ:qmnslaveidlewait1670.004,611276110.03StreamsAQ:qmncoordinatoridlewait35147.864,611131370.06smontimer2776.504,531163560.05StreamsAQ:waitingfortimemanagementorcleanuptasks

53、1100.002702697470.00PXDeq:ParseReply4040.00030.01PXDeq:JoinACK3842.11010.01PXDeq:ExecuteReply3432.35000.01StreamsAQ:RACqmncoordinatoridlewait351100.00000.06BacktoWaitEventsStatisticsBacktoTopOperatingSystemStatisticsStatisticTotalNUM_LCPUS0NUM_VCPUS0AVG_BUSY_TIME101,442AVG_IDLE_TIME371,241AVG_IOWAIT

54、_TIME5,460AVG_SYS_TIME25,795AVG_USER_TIME75,510BUSY_TIME812,644IDLE_TIME2,971,077IOWAIT_TIME44,794SYS_TIME207,429USER_TIME605,215LOAD0OS_CPU_WAIT_TIME854,100RSRC_MGR_CPU_WAIT_TIME0PHYSICAL_MEMORY_BYTES8,589,934,592NUM_CPUS8NUM_CPU_CORES4如果显示 0,是因为没有设置 LPARS 同上。BUSY_TIME/NUM_CPUSIDLE_TIME/NUM_CPUSIOW

55、AIT_TIME/NUM_CPUSSYS_TIME/NUM_CPUSUSER_TIME/NUM_CPUSarotimeequivof%usr+%sysinsaroutputtimeequivof%idleinsartimeequivof%wioinsartimeequivof%sysinsarUSER_TIME：timeequivof%usrinsarLOAD:未知OS_CPU_WAIT_TIME:supposedlytimewaitingonrunqueuesRSRC_MGR_CPU_WAIT_TIME:timewaitedcozofresourcemanagerPHYSICAL_MEMOR

56、Y_BYTES:totalmemoryinusesupposedlyNUM_CPUS:numberofCPUsreportedbyOSNUM_CPU_CORES:numberofCPUsocketsonmotherboardNUM_LCPUS:NUM_VCPUS:AVG_BUSY_TIME:AVG_IDLE_TIME:AVG_IOWAIT_TIMEAVG_SYS_TIME:AVG_USER_TIME:BUSY_TIME:IDLE_TIME:IOWAIT_TIME:SYS_TIME:总的 elapsedtime 也可以用以公式计算：BUSY_TIME+IDLE_TIME+IOWAITTIME或：

57、SYS_TIME+USER_TIME+IDLE_TIME+IOWAIT_TIME(因为 BUSY_TIME=SYS_TIME+USER_TIME)BacktoWaitEventsStatisticsBacktoTopServiceStatisticsorderedbyDBTimeServiceNameDBTime(s)DBCPU(s)PhysicalReadsLogicalReadsICCI608.10496.60315,84916,550,972SYS$USERS54.7017.806,53958,929ICCIXDB0.000.0000SYS$BACKGROUND0.000.0028238

58、,990BacktoWaitEventsStatisticsBacktoTopServiceWaitClassStatsWaitClassinfoforservicesintheServiceStatisticssection.TotalWaitsandTimeWaiteddisplayedforthefollowingwaitclasses:UserI/O,Concurrency,Administrative,NetworkTimeWaited(WtTime)incentisecond(100thofasecond)ServiceNameUserI/OTotalWtsUserI/OWtTim

59、eConcurcyTotalWtsConcurcyWtTimeAdminTotalWtsAdminWtTimeNetworkTotalWtsNetworkWtTimeICCI59826864046213380015640596552SYS$USERS65673238231110073233SYS$BACKGROUND4431153301680000BacktoWaitEventsStatisticsBacktoTopSQLStatisticsSQLorderedbyElapsedTimeSQLorderedbyCPUTimeSQLorderedbyGetsSQLorderedbyReadsSQ

60、LorderedbyExecutionsSQLorderedbyParseCallsSQLorderedbySharableMemorySQLorderedbyVersionCountSQLorderedbyClusterWaitTimeCompleteListofSQLText本节按各种资源分别列出对资源消耗最严重的 SQL 语句，并显示它们所占统计期内全部资源的比例，这给出我们调优指南。例如在一个系统中，CPU 资源是系统性能瓶颈所在，那么优化 buffergets 最多的 SQL 语句将获得最大效果。在一个 I/O 等待是最严重事件的系统中，调优的目标应该是 physicalIOs 最多的 SQ