《Oracle_AWR_报告分析实例讲.pdf》由会员分享，可在线阅读，更多相关《Oracle_AWR_报告分析实例讲.pdf（47页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、WORKLOAD REPOSITORY report for DB Name DB Id Instance Inst num Release RAC Host ICCI 1314098396 ICCI1 1 10.2.0.3.0 YES HPGICCI1 Snap Id Snap Time Sessions Cursors/Session Begin Snap:2678 25-Dec-08 14:04:50 24 1.5 End Snap:2680 25-Dec-08 15:23:37 26 1.5 Elapsed:78.79(mins)DB Time:11.05(mins)Elapsed表示
2、整个 AWR 报表统计的时间长度DB Time 是记录在服务器花在数据库运算（非后台进程）和等待（非空闲等待）上的时间DB Time=cpu time+wait time（不包含空闲等待）（非后台进程）DB Time 不包括 Oracle后台进程消耗的时间。如果 DB Time 远远小于 Elapsed时间，说明数据库比较空闲。上述报表中Snapshot时间间隔约为 79 分钟，cpu 就公有 8*79=632 分钟。DB Time 为 11.05分钟，则：cpu花费了 11.05 分钟在处理 oracle非空闲等待和运算上（比如逻辑读），也就是说 cpu有 11.05/632=0.017%花
3、费在处理 oracle的操作上。从 awr report 的 Elapsed time和 DB Time 就能大概了解 db的负载，计算公式可参考为：cpu负载=DB Time/(cpu 数*Elapsed)*100%在 79 分钟里（其间收集了3 次快照数据），数据库耗时11 分钟，RDA 数据中显示系统有 8 个逻辑 CPU（4 个物理 CPU），平均每个 CPU耗时 1.4 分钟，CPU 利用率只有大约2%（1.4/79）。说明系统压力非常小。可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分
4、析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。Report SummaryCache Sizes Begin End Buffer Cache:3,344M 3,344M Std Block Size:8K Shared Pool Size:704M 704M Log Buffer:14,352K 显示 SGA 中每个区域的大小（在AMM 改变它们之后），可用来与初始参数值比较。shared pool主要包括 library cache和 dictionary cache。library cache用来存储最近解析（或编译）后SQL、PL/SQL 和 Jav
5、a classes 等。library cache用来存储最近引用的数据字典。发生在library cache或 dictionary cache的 cache miss代价要比发生在 buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被 cache。Load Profile Per Second Per Transaction DB Time（s）2.4 0.0 Redo size:918,805.72 775,912.72 Logical reads:3,521.77 2,974.06 Block changes:1,817.95 1,535.2
6、2 Physical reads:68.26 57.64 Physical writes:362.59 306.20 User calls:326.69 275.88 Parses:38.66 32.65 Hard parses:0.03 0.03 Sorts:0.61 0.51 Logons:0.01 0.01 Executes:354.34 299.23 Transactions:1.18%Blocks changed per Read:51.62 Recursive Call%:51.72 Rollback per transaction%:85.49 Rows per Sort:#显示
7、数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，然而Logons 大于每秒 12个、Hard parses大于每秒 100、全部 parses超过每秒 300 表明可能有争用问题。DB Time（s）：每秒内用于DB 处理的时间，其他时间为等待时间Redo size：每秒/每事务产生的 redo 大小（单位字节），可标志数据库任务的繁重程序。其中 Per Second表示每秒中产生的redo的字节数，Per Transaction表示每个事务产生的redo 的字节
8、数，可以通过后者可以看到事务的大小，协助判断是否 commit 次数太多。例如 per second很大，而 per transaction很小，说明commit 次数太多。通常在很繁忙的系统中日志生成量可能达到上百k，甚至几百k。Logical reads：每秒/每事务逻辑读的块数（我们可以这样认为，block 在内存中，我们每一次读一块内存，就相当于一次逻辑读），单位为块，在良好的 OLTP环境中，Logical reads/Executes不会超过 50，一般只有 10左右，如果该指标较大，表示语句可能不够优化，需要具体分析，在该示例中，3,521.77/354.34,那么在 OLAP
9、中呢？Block changes：每秒/每事务修改的块数，即每秒中多少个块发生变化Physical reads：每秒/每事务物理读的块数，即每秒数据库从磁盘读取的块个数Physical writes：每秒/每事务物理写的块数，即每秒有多少个块接受了数据库写入数据。User calls：每秒/每事务用户 call 次数 User calls/Executes基本代表每个语句的请求次数，Executes越接近 User calls越好。Parses：每秒的 SQL 语句解析的次数，超过300 即需要关注，可以考虑调整参数 session_cursor_cache 来改善解析次数过高的现象。Hard
10、 parses：其中硬解析的次数，如果硬解析次数太高，说明SQL 重用率不高。例如超过 100，基本都是由于不使用bind var 所导致的，导致 cpu 使用率的问题，极有使得性能急剧下降。Sorts：每秒/每事务的排序次数Logons：每秒/每事务登录的次数Executes：每秒/每事务 SQL 执行次数，包括用户执行的 sql 语句与系统执行的sql 语句，表示一个系统sql 的繁忙程度。Transactions：每秒产生的事物个数，反映数据库负载程度，不同的系统，略有差异，在典型的交易系统中，事务较多，而网站系统，可能select查询较多。Blocks changed per Read
11、：表示逻辑读用于修改数据块的比例Recursive Call：递归调用占所有操作的比率Rollback per transaction：每事务的回滚率Rollbacks：表示数据库中事务的回退率，如果不是因为业务本身的原因，通常应该小于 10%为好，回退是一个很消耗资源的操作。Rows per Sort：每次排序的行数注:Oracle的硬解析和软解析提到软解析(soft parse)和硬解析(hard parse)，就不能不说一下Oracle对 sql的处理过程。当你发出一条sql 语句交付 Oracle，在执行和获取结果前，Oracle对此 sql 将进行几个步骤的处理过程：1、语法检查(s
12、yntax check)检查此 sql 的拼写是否语法。2、语义检查(semantic check)诸如检查 sql 语句中的访问对象是否存在及该用户是否具备相应的权限。3、对 sql 语句进行解析(parse)利用内部算法对 sql 进行解析，生成解析树(parse tree)及执行计划(execution plan)。4、执行 sql，返回结果(execute and return)其中，软、硬解析就发生在第三个过程里。Oracle利用内部的 hash算法来取得该 sql的 hash值，然后在 library cache里查找是否存在该 hash值；假设存在，则将此sql 与 cache中
13、的进行比较；假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。诚然，如果上面的 2 个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。创建解析树、生成执行计划对于sql 的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。Instance Efficiency Percentages(Target 100%)Buffer Nowait%:100.00 Redo NoWait%:100.00 Buffer Hit%:98.72 In-memory Sort%:99.86 Library Hi
14、t%:99.97 Soft Parse%:99.92 Execute to Parse%:89.09 Latch Hit%:99.99 Parse CPU to Parse Elapsd%:7.99%Non-Parse CPU:99.95 本节包含了 Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中 Buffer Hit Ratio 也称 Cache Hit Ratio，Library Hit ratio 也称 Library Cache Hit ratio。同 Load Profile 一节相同，这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。在一个使用直接读
15、执行大型并行查询的DSS环境，20%的 Buffer Hit Ratio 是可以接受的，而这个值对于一个OLTP 系统是完全不能接受的。根据 Oracle的经验，对于 OLTPT 系统，Buffer Hit Ratio 理想应该在 90%以上。Buffer Nowait%表示在数据缓冲区中获取的buffer 时，未进行等待的比率，越高越好。buffer hit%表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP 系统，命中率通常在95以上，如果此值低于 80%，应该给数据库分配更多的内存，考虑加大db_cache_size。在数据仓库 OLAP
16、环境中，数据缓冲命中率不是一个重要的指标，因为OLAP 数据库主要是物理读，甚至是直接读，该命中率不可能高。Redo NoWai%t 表示在 LOG 缓冲区获得 BUFFER 的未等待比例。如果太低（可参考 90%阀值），考虑增加LOG BUFFER。library hit%表示 Oracle从 Library Cache中检索到一个解析过的SQL或 PL/SQL语句的比率，当应用程序调用SQL 或存储过程时，Oracle检查 Library Cache 确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在Library Cache 中为它分配
17、共享SQL 区。低的 library hit ratio会导致过多的解析，增加 CPU 消耗，降低性能。Sql 语句在库缓冲中能否找到相应的解析计划，如果library hit ratio 低于 90%，可能需要调大 shared pool区，或检查是否有硬编码现象。Latch Hit%：Latch 是一种保护内存结构的锁，可以认为是SERVER 进程获取访问内存数据结构的许可,表示内部结构维护锁命中率。要确保Latch Hit99%，否则意味着 Shared Pool latch争用，可能由于未共享的SQL，或者 Library Cache太小，可使用绑定变更或调大Shared Pool解决
18、。Parse CPU to Parse Elapsd：表示解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。在实际繁忙的系统中，该值可能因为等待资源而不会太高。Non-Parse CPU：SQL 实际运行时间/(SQL 实际运行时间+SQL 解析时间)，太低表示解析消耗时间过多。说明解析时间所占比率过高，需要考虑提高sql 语句重用性。Execute to Parse：是语句执行与分析的比例,表示 sql 语句解析后被重复执行的命中率，计算公式=100*（1-Parses/Executions）,如果该值偏小，说明分析（硬分析和软分析）的比例较大，快速分析较少，根据实际情况
19、，可以考虑调整session_cached_cursors 参数，有些报告中这个值是负的，看上去很奇怪，事实上这表示一个问题，sql 如果被 age out的话就可能出现这种情况，也就是 sql 老化，执行 alter system flush shared_pool 如果要 SQL 重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。Soft Parse%：SQL 语句软解析占整个分析的命中率，如果低于95，需检查是否有硬编码现象，如果低于80，说明 sql 语句基本没有重用性=soft/(soft+hard)In-memory Sort：在内存中排序的比率，即有多少排序
20、在内存中进行的，如果过低说明有大量的排序在临时表空间中进行，性能肯定不好，考虑调大PGA 参数，sort_area_size。Soft Parse：软解析的百分比（softs/softs+hards），近似当作 sql 在共享区的命中率，太低则需要调整应用使用绑定变量。Shared Pool Statistics Begin End Memory Usage%:47.19 47.50%SQL with executions1:88.48 79.81%Memory for SQL w/exec1:79.99 73.52 Memory Usage%：表示共享池内存使用率，对于一个已经运行一段时间的
21、数据库来说，共享池内存使用率，应该稳定在 75%-90%间，如果太小，说明 Shared Pool 有浪费，而如果高于90，说明共享池中有争用，内存不足。SQL with executions1：执行次数大于 1 的 sql 比率，如果此值太小的话要结合 Parse，看看是不是硬编码现象，说明需要在应用中更多使用绑定变量，避免过多 SQL 解析。Memory for SQL w/exec1：执行次数大于1 的 SQL 消耗内存的占比。Top 5 Timed Events Event Waits Time(s)Avg Wait(ms)%Total Call Time Wait Class CPU
22、 time 515 77.6 SQL*Net more data from client 27,319 64 2 9.7 Network log file parallel write 5,497 47 9 7.1 System I/O db file sequential read 7,900 35 4 5.3 User I/O db file parallel write 4,806 34 7 5.1 System I/O 这是报告概要的最后一节，显示了系统中最严重的5个等待，按所占等待时间的比例倒序列示。当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。例如
23、如果buffer busy wait是较严重的等待事件，我们应当继续研究报告中Buffer Wait 和 File/Tablespace IO区的内容，识别哪些文件导致了问题。如果最严重的等待事件是I/O 事件，我们应当研究按物理读排序的 SQL 语句区以识别哪些语句在执行大量I/O，并研究 Tablespace和 I/O 区观察较慢响应时间的文件。如果有较高的 LATCH 等待，就需要察看详细的LATCH统计识别哪些 LATCH 产生的问题。在这里，log file parallel write 是相对比较多的等待，占用了7%的 CPU 时间。通常，在没有问题的数据库中，CPU time 总
24、是列在第一个。更多的等待事件，参见本报告的 Wait Events 一节。RAC Statistics Begin End Number of Instances:2 2 Global Cache Load Profile Per Second Per Transaction Global Cache blocks received:4.16 3.51 Global Cache blocks served:5.97 5.04 GCS/GES messages received:408.47 344.95 GCS/GES messages sent:258.03 217.90 DBWR Fusi
25、on writes:0.05 0.05 Estd Interconnect traffic(KB)211.16 Global Cache Efficiency Percentages(Target local+remote 100%)Buffer access-local cache%:98.60 Buffer access-remote cache%:0.12 Buffer access-disk%:1.28 Global Cache and Enqueue Services-Workload Characteristics Avg global enqueue get time(ms):0
26、.1 Avg global cache cr block receive time(ms):1.1 Avg global cache current block receive time(ms):0.8 Avg global cache cr block build time(ms):0.0 Avg global cache cr block send time(ms):0.0 Global cache log flushes for cr blocks served%:3.5 Avg global cache cr block flush time(ms):3.9 Avg global ca
27、che current block pin time(ms):0.0 Avg global cache current block send time(ms):0.0 Global cache log flushes for current blocks served%:0.4 Avg global cache current block flush time(ms):3.0 Global Cache and Enqueue Services-Messaging Statistics Avg message sent queue time(ms):0.0 Avg message sent qu
28、eue time on ksxp(ms):0.3 Avg message received queue time(ms):0.5 Avg GCS message process time(ms):0.0 Avg GES message process time(ms):0.0%of direct sent messages:14.40%of indirect sent messages:77.04%of flow controlled messages:8.56 Main Report Wait Events StatisticsSQL StatisticsInstance Activity
29、StatisticsIO StatsBuffer Pool StatisticsAdvisory StatisticsWait StatisticsUndo StatisticsLatch StatisticsSegment StatisticsDictionary Cache StatisticsLibrary Cache StatisticsMemory StatisticsStreams StatisticsResource Limit Statisticsinit.ora ParametersWait Events Statistics Time Model Statistics Wa
30、it Class Wait Events Background Wait Events Operating System Statistics Service Statistics Service Wait Class Stats Back to TopTime Model Statistics Total time in database user-calls(DB Time):663s Statistics including the word background measure background process time,and so do not contribute to th
31、e DB time statistic Ordered by%or DB time desc,Statistic name Statistic Name Time(s)%of DB Time DB CPU 514.50 77.61 sql execute elapsed time 482.27 72.74 parse time elapsed 3.76 0.57 PL/SQL execution elapsed time 0.50 0.08 hard parse elapsed time 0.34 0.05 connection management call elapsed time 0.0
32、8 0.01 hard parse(sharing criteria)elapsed time 0.00 0.00 repeated bind elapsed time 0.00 0.00 PL/SQL compilation elapsed time 0.00 0.00 failed parse elapsed time 0.00 0.00 DB time 662.97 background elapsed time 185.19 background cpu time 67.48 此节显示了各种类型的数据库处理任务所占用的CPU 时间。Back to Wait Events Statist
33、icsBack to TopWait Class s-second cs-centisecond-100th of a second ms-millisecond-1000th of a second us-microsecond-1000000th of a second ordered by wait time desc,waits desc Wait Class Waits%Time-outs Total Wait Time(s)Avg wait(ms)Waits/txn User I/O 66,837 0.00 120 2 11.94 System I/O 28,295 0.00 93
34、 3 5.05 Network 1,571,450 0.00 66 0 280.72 Cluster 210,548 0.00 29 0 37.61 Other 81,783 71.82 28 0 14.61 Application 333,155 0.00 16 0 59.51 Concurrency 5,182 0.04 5 1 0.93 Commit 919 0.00 4 4 0.16 Configuration 25,427 99.46 1 0 4.54 Back to Wait Events StatisticsBack to TopWait Events s-second cs-c
35、entisecond-100th of a second ms-millisecond-1000th of a second us-microsecond-1000000th of a second ordered by wait time desc,waits desc(idle events last)Event Waits%Time-outs Total Wait Time(s)Avg wait(ms)Waits/txn SQL*Net more data from client 27,319 0.00 64 2 4.88 log file parallel write 5,497 0.
36、00 47 9 0.98 db file sequential read 7,900 0.00 35 4 1.41 db file parallel write 4,806 0.00 34 7 0.86 db file scattered read 10,310 0.00 31 3 1.84 direct path write 42,724 0.00 30 1 7.63 reliable message 355 2.82 18 49 0.06 SQL*Net break/reset to client 333,084 0.00 16 0 59.50 db file parallel read
37、3,732 0.00 13 4 0.67 gc current multi block request 175,710 0.00 10 0 31.39 control file sequential read 15,974 0.00 10 1 2.85 direct path read temp 1,873 0.00 9 5 0.33 gc cr multi block request 20,877 0.00 8 0 3.73 log file sync 919 0.00 4 4 0.16 gc cr block busy 526 0.00 3 6 0.09 enq:FB-contention
38、 10,384 0.00 3 0 1.85 DFS lock handle 3,517 0.00 3 1 0.63 control file parallel write 1,946 0.00 3 1 0.35 gc current block 2-way 4,165 0.00 2 0 0.74 library cache lock 432 0.00 2 4 0.08 name-service call wait 22 0.00 2 76 0.00 row cache lock 3,894 0.00 2 0 0.70 gcs log flush sync 1,259 42.02 2 1 0.2
39、2 os thread startup 18 5.56 2 89 0.00 gc cr block 2-way 3,671 0.00 2 0 0.66 gc current block busy 113 0.00 1 12 0.02 SQL*Net message to client 1,544,115 0.00 1 0 275.83 gc buffer busy 15 6.67 1 70 0.00 gc cr disk read 3,272 0.00 1 0 0.58 direct path write temp 159 0.00 1 5 0.03 gc current grant busy
40、 898 0.00 1 1 0.16 log file switch completion 29 0.00 1 17 0.01 CGS wait for IPC msg 48,739 99.87 0 0 8.71 gc current grant 2-way 1,142 0.00 0 0 0.20 kjbdrmcvtq lmon drm quiesce:ping completion 9 0.00 0 19 0.00 enq:US-contention 567 0.00 0 0 0.10 direct path read 138 0.00 0 1 0.02 enq:WF-contention
41、14 0.00 0 9 0.00 ksxr poll remote instances 13,291 58.45 0 0 2.37 library cache pin 211 0.00 0 1 0.04 ges global resource directory to be frozen 9 100.00 0 10 0.00 wait for scn ack 583 0.00 0 0 0.10 log file sequential read 36 0.00 0 2 0.01 undo segment extension 25,342 99.79 0 0 4.53 rdbms ipc repl
42、y 279 0.00 0 0 0.05 ktfbtgex 6 100.00 0 10 0.00 enq:HW-contention 44 0.00 0 1 0.01 gc cr grant 2-way 158 0.00 0 0 0.03 enq:TX-index contention 1 0.00 0 34 0.00 enq:CF-contention 64 0.00 0 1 0.01 PX Deq:Signal ACK 37 21.62 0 1 0.01 latch free 3 0.00 0 10 0.00 buffer busy waits 625 0.16 0 0 0.11 KJC:W
43、ait for msg sends to complete 154 0.00 0 0 0.03 log buffer space 11 0.00 0 2 0.00 enq:PS-contention 46 0.00 0 1 0.01 enq:TM-contention 70 0.00 0 0 0.01 IPC send completion sync 40 100.00 0 0 0.01 PX Deq:reap credit 1,544 99.81 0 0 0.28 log file single write 36 0.00 0 0 0.01 enq:TT-contention 46 0.00
44、 0 0 0.01 enq:TD-KTF dump entries 12 0.00 0 1 0.00 read by other session 1 0.00 0 12 0.00 LGWR wait for redo copy 540 0.00 0 0 0.10 PX Deq Credit:send blkd 17 5.88 0 0 0.00 enq:TA-contention 14 0.00 0 0 0.00 latch:ges resource hash list 44 0.00 0 0 0.01 enq:PI-contention 8 0.00 0 0 0.00 write comple
45、te waits 1 0.00 0 2 0.00 enq:DR-contention 3 0.00 0 0 0.00 enq:MW-contention 3 0.00 0 0 0.00 enq:TS-contention 3 0.00 0 0 0.00 PX qref latch 150 100.00 0 0 0.03 enq:MD-contention 2 0.00 0 0 0.00 latch:KCL gc element parent latch 11 0.00 0 0 0.00 enq:JS-job run lock-synchronize 1 0.00 0 1 0.00 SQL*Ne
46、t more data to client 16 0.00 0 0 0.00 latch:cache buffers lru chain 1 0.00 0 0 0.00 enq:UL-contention 1 0.00 0 0 0.00 gc current split 1 0.00 0 0 0.00 enq:AF-task serialization 1 0.00 0 0 0.00 latch:object queue header operation 3 0.00 0 0 0.00 latch:cache buffers chains 1 0.00 0 0 0.00 latch:enque
47、ue hash chains 2 0.00 0 0 0.00 SQL*Net message from client 1,544,113 0.00 12,626 8 275.83 gcs remote message 634,884 98.64 9,203 14 113.41 DIAG idle wait 23,628 0.00 4,616 195 4.22 ges remote message 149,591 93.45 4,612 31 26.72 Streams AQ:qmn slave idle wait 167 0.00 4,611 27611 0.03 Streams AQ:qmn
48、 coordinator idle wait 351 47.86 4,611 13137 0.06 Streams AQ:waiting for messages in the queue 488 100.00 4,605 9436 0.09 virtual circuit status 157 100.00 4,596 29272 0.03 PX Idle Wait 1,072 97.11 2,581 2407 0.19 jobq slave wait 145 97.93 420 2896 0.03 Streams AQ:waiting for time management or clea
49、nup tasks 1 100.00 270 269747 0.00 PX Deq:Parse Reply 40 40.00 0 3 0.01 PX Deq:Execution Msg 121 26.45 0 0 0.02 PX Deq:Join ACK 38 42.11 0 1 0.01 PX Deq:Execute Reply 34 32.35 0 0 0.01 PX Deq:Msg Fragment 16 0.00 0 0 0.00 Streams AQ:RAC qmn coordinator idle wait 351 100.00 0 0 0.06 class slave wait
50、2 0.00 0 0 0.00 db file scattered read等待事件是当 SESSION 等待 multi-block I/O 时发生的，通过是由于 full table scans或 index fast full scans。发生过多读操作的Segments可以在“Segments by Physical Reads”和“SQL ordered by Reads”节中识别（在其它版本的报告中，可能是别的名称）。如果在OLTP 应用中，不应该有过多的全扫描操作，而应使用选择性好的索引操作。DB file sequential read等待意味着发生顺序I/O 读等待（通常是单