14. Awr报告指标查看

AWR报告分析

1.1 AWR报告之DB time

　　DB Time 主要用于判断当前系统有没有相关的瓶颈，是否较为频繁访问系统导致等待时间很长？ 一般来说，Elapsed 时间乘以CPU个树，如果大于DB Time，就是正常的，系统压力不大，反之就说明压力较大。

1.2 AWR之load_profile

     load_profile 指标主要用来显示当前系统的一些指示性能的总体参数，

　　这里的redo size有两个指标，一个是每秒产生的redo的大小，一个是每个事务产生的redo的大小，一般来说transactions不超过200都是正常的，或者200左右都是正常的，超多1000就是非常繁忙了，

1.3 AWR之Instance Efficiency Percentages

     efficiency percentages 是一些命中率指标，buffer hint、libray hint等表示SGA的命令率；soft parse指标表示共享池的软解析率，如果小于90%，就说明存在未绑定变量的情况。

一些命中率指标：

• Buffer Nowait：表示在内存获得数据的未等待比例，理想状态是100%，如低于99%，则表示数据库可能存在资源争用情况。
• Buffer Hit：表示进程从内存块中获得数据的比例。
• Library Hit：如上文，软解析就是从库缓冲中获取到sql执行计划，这个比例太低会导致硬解析过多。
• Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
• Parse CPU to Parse Elapsed：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。
• Redo Nowait：在log缓冲区中不等待比例。
• In-Memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA(10g)。如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决，注意这两个参数设置作用的范围时不同的，SORT_AREA_SIZE是针对每个session设置的，PGA_AGGREGATE_TARGET则时针对所有的sesion的。
• Soft Parse：软解析的百分比(Softs/Softs+Hards)，近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。sql在共享区的命中率，小于<95%,需要考虑绑定，如果低于80%，那么就可以认为sql基本没有被重用。
• Latch Hit：Latch是一种保护内存结构的锁，可以认为是Server进程获取访问内存数据结构的许可。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。要确保>99%，否则存在严重的性能问题。当该值出现问题的时候，我们可以借助后面的等待时间和latch分析来查找解决问题。

1.4 AWR之top 10 events

    top 10 Foreground Events by total wait time，等待事件是衡量数据库优化情况的重要指标，通过观察Event和%DB time两列就可以直观看出当前数据库的主要等待事件。

主要看这两列，看占用DB time的百分比。

几个常见的top事件：

• db file scattered read：文件散列读取等待即多块读等待事件是当SESSION等待multi-block I/O时发生的，通常是由于full table scans或index fast full scans引起，Avg wait>20ms就要注意了，db file scattered read 异常大，可能是由于全表扫描引起

      该事件通常与全表扫描或者index fast full scan有关。因为全表扫描是被放入内存中进行的，通常情况下基于性能的考虑，有时候也可能是分配不到足够长的连续内存空间，所以会将数据块分散(scattered)读入Buffer Cache中。该等待过大可能是缺少索引或者没有合适的索引(可以调整optimizer_index_cost_adj) 。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。因为全表扫描被置于LRU(Least Recently Used，最近最少适用)列表的冷端(cold end)，对于频繁访问的较小的数据表，可以选择把他们Cache 到内存中，以避免反复读取。当这个等待事件比较显著时，可以结合v$session_longops 动态性能视图来进行诊断，该视图中记录了长时间(运行时间超过6 秒的)运行的事物

• DB file sequential read：单块读等待意味着发生顺序I/O读等待,如果这个等待严重，则应该对大表进行分区以减少I/O量，或者优化执行计划（通过使用存储大纲或执行数据分析）以避免单块读操作引起的sequential read等待，通常由于INDEX FULL SCAN/UNIQUE SCAN 、INDEX RANGE SCAN、行迁移或行链接引起，Avg wait>20ms就要注意了。

     这里的sequential指的是将数据块读入到相连的内存空间中(contiguous memory space)，而不是指所读取的数据块是连续的。1、最为常见的是执行计划中包含了INDEX FULL SCAN/UNIQUE SCAN,此时出现”db file sequential read”等待是预料之中的3、当执行计划包含了INDEX RANGE SCAN-(“TABLE ACCESS BY INDEX ROWID”/”DELETE”/”UPDATE”)， 服务进程将按照”访问索引->找到rowid->访问rowid指定的表数据块并执行必要的操作”顺序访问index和table，每次物理读取都会进入”db file sequential read”等待，且每次读取的都是一个数据块；这种情况下clustering_factor将发挥其作用（ALL_INDEXES的CLUSTERING_FACTOR*值来判断数据的离散程度）3、Extent boundary,假设一个Extent区间中有33个数据块，而一次”db file scattered read”多块读所读取的块数为8，那么在读取这个区间时经过4次多块读取后，还剩下一个数据块，但是请记住多块读scattered read是不能跨越一个区间的(span an extent)，此时就会单块读取并出现”db file sequential read”。4、假设某个区间内有8个数据块，它们可以是块a,b,c,d,e,f,g,h，恰好当前系统中除了d块外的其他数据块都已经被缓存在buffer cache中了，而这时候恰好要访问这个区间中的数据，那么此时就会单块读取d这个数据块，并出现”db file sequential read”等待。注意这种情况不仅于表，也可能发生在索引上。

• Buffer Busy Waits：该事件是在一个SESSION需要访问BUFFER CACHE中的一个数据库块而又不能访问时发生的（指的是多个session对于同一个block的写入竞争）出现在两个session都是写入时。
• read by other session：多个session并发请求相同的数据块，但因该数据块不在buffer_cache中而必须从磁盘读取，处理这种情况，oracle会只让其中一个sesion进行磁盘读取，此时其它session等待块从磁盘上读取进buffer_cache而抛出read by other session等待事件。
• gc buffer busy：相当于rac集群下的Buffer Busy Waits.
• gc buffer busy acquire：与上面一致。

等待事件可以查看前面的文章：https://www.cnblogs.com/zmc60/p/17034679.html