--AWR报告
一、第一部分--数据库基本信息
1.快照窗口的持续时间
2.报告开始和结束的会话数量--在报告期间负载的恒定的、增加的还是减少的？
二、第二部分--负载信息
1.logical reads:逻辑读
2.block changes:块更改
3.physical reads：物理读
4.physical writes:物理写
5.user calls :用户调用
6.parses：解析
7.hard parses:硬解析
8.W/A MB processed:工作区域处理---排序操作
****调查数据缓存区是否被正确使用，是否需要添加数据块缓冲区大小****
1.buffer nowait --缓冲区无等待率
2.buffer hit --缓冲区命中率
*****库缓存区很低，考虑增加共享池;查询是否因为不恰当的绑定变量被使用**
3.library hit --库缓存区
***重做无等待百分表示重做缓冲区被利用了，如果低，需要对重做日志缓冲区和重做日志进行调优***
4.redo nowait ---重做无等待
****parse CPU to parse elapsd 如果低，表示在整个解析过程中，实际在CPU上运算的时间很短，主要的解析时间都消耗在其他分空闲等待上面了***
5.execute to parse --执行解析
6.parse CPU to parse elapsd --解析CPU时间和总解析时间比
***PGA_AGGREGATE_TARGET 参数或者 手工配置时的 SORT_AREAA_SIZE,HASH_AREA_SIZE 参数，位图设置是否需要检查 ***
7.memory sort --内存排序---如果百分比小于100，表示排序在磁盘进行;磁盘排序是缓慢的，可能导致严重的性能问题
******
8.soft parse --软解析，我们提交的SQL语句在游标缓存中找到的频率;--硬解析会导致递归SQL
9.latch hit ---(shuān)闩锁命中率---如果百分比低，需要查询CPU受限进程和闩锁的问题
10.非解析(non-parse)CPU百分比---CPU在处理请求时候花费的时间，--如果低，表示系统花费了很多时间在处理SQL语句，没有足够的时间做真正的工作
三、等待事件、CPU、内存的统计数据
****注意：在一个适当调优的系统中，CPU使用率应该占主导地位***
1.RAC环境中占主导地位的等待事件可能是与重做日志相关的，互联相关的或者撤销表空间相关的
2.gc current block 2-way 说明相同的块在节点互联中被来回共享
3.主要等待时间是 db file sequential read 表示单块读取(索引读)引起的问题;--解决办法：增加更多的DB块缓存内存(服务器内存)
****1.通过增加磁盘阵列中磁盘的数量，使读操作的文件更分散;2.进一步降低这个等待事件的方法是通过提升服务器的内存数量或者通过移动数据到全闪阵列来减少读延迟
****当I/O系统压力较大时，通常看见的另一个等待是 db file scattered read，表示发生了全表或者全索引扫描
****1.全表扫描可以通过适当的索引来纠正;2.或者可以使用分区减少扫描的数据量3.唯一解决办法:通过大规模的缓存或者使用全闪存阵列来减少延迟
****当db file sequential read 或者db file scattered read 成为重要等待时，DBA需要查看报告的SQL部分;通常出现在两个或者更多的SQL字句中，他就是调优操作的最佳候选对象
4.日志文件压力(重做日志)的一个关键指标是log file sync;log file parallel write;log file sequential write;log file single write和log file switch completion 占top主导地位
****必须确保等待是真正的来自于I/O 相关的问题，而不是归档日志之类的问题
****1.通常日志文件放在数据和索引文件相同的物理磁盘上时，日志文件压力就会出现
****2.可以将日志文件转移到自己的磁盘阵列;或者在使用基于闪存的存储系统时，使用单个逻辑单元号lun将日志文件从其他文件中分离出来，缓解日志文件的压力
5. Host CPU *** load average begin/end 表示有多少个进程正在等待
6.Instance CPU 显示 实例使用CPU 的效率有多高
7.Memory Statistics 内存使用
*** % Host Mem used for SGA+PGA: 表示使用系统多少内存
*** SGA use (MB):276,480.0 到 276,480.0 很稳定
*** PGA use (MB):1,856.4 到 1,869.1 增加了 12.7M
8.RAC 持有界面 ;在头部和系统配置区域之后是一个RAC持有 章节
RAC Statistics
9.Time Model Statistics CPU 时间分类
****注意:如果解析时间和硬解析时间值很接近，那么就是产生了过渡的硬解析******
10.Operating System Statistics 操作系统统计信息
***空闲时间(%idle)和I/O等待事件的统计值大于繁忙(%busy)时间值
11.Foreground Wait Class 前台等待事件---前台进程是用户或者应用程序级的进程
%DB time 时间中占用不到0.1%的等待事件可以忽略;
***RAC环境中看到大量的 read by other session 的等待事件,通常表块太大或者延迟太大，从而导致争用;
***如果 read by other session 是主要等待事件之一，那么看awr 报告中 segments by x 部分确认那些表和索引正在被大量使用
***可以考虑将这些段移到一个小于默认块大小的表空间，比如4KB或者2KB，或者降低存储延迟(IBM FlashSystem减少这种争用)
12.Background Wait Events 后台等待事件 --Oracle进程堆栈中众多后台进程生产的等待(DBWR LGWR SMON PMON )
*** control file sequential re 或者 control file parallel write 属于I/O等待事件相关的等待
13.Wait Event Histogram 等待事件直方图---基于时间的直方图报告
***直方图报告，根据时间名称来排序的
***读等待事件比写等待事件更重要
***磁盘正在承受压力---1通过增加磁盘阵列中的磁盘数量2.提供更大IOPS的选择是使用IBM的闪存技术
14.Service Statistics 服务相关统计数据
***服务是一组用于提供公共功能的进程(比如:用于为同一用户提供一系列SQL语句的所有并行查询的子进程(slaves)和进程(processes)都可以被分到一个服务中)
***1s等于1000ms;基于磁盘的非缓存系统的最佳等待时间是5ms
15.SQL章节
SQL ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by User I/O Wait Time
SQL ordered by Gets
SQL ordered by Reads
SQL ordered by Physical Reads (UnOptimized)
SQL ordered by Executions
SQL ordered by Parse Calls
SQL ordered by Sharable Memory
SQL ordered by Version Count
SQL ordered by Cluster Wait Time
******SQL语句出现在以上两个或者多个区域的TOP5语句中，那么它就是调优的主要候选对象
***15.1 如果一个SQL语句出现在报告的总运行时间(Elapsed Time)区域内，表示它的CPU时间加上其他的等待时间很高;
***如果由于某种原因，SQL处于总运行时间的顶部，而不是总CPU时间的顶部，则表明改SQL语句存在与递归调用有关的问题(比如:不佳的解析率);
***15.2 SQL语句出现在总CPU时间(CPU Time)部分时，则表明它在处理期间使用了过多的CPU周期
***过多的CPU处理时间可能是由:排序、过多的函数和长时间的解析造成的;
***为了减少CPU可以使用排序消除器多的多列索引来减少排序，也可以使用绑定变量来减少解析时间
******小窍门:如果SQL是大写的，那么它可能来自于用户或者应用程序;如果是小写的，则通常来自内部或者后台进程;所有表字段中包含单引号的SQL通常是工具产生的******
***15.3 高总缓冲区获取表明SQL语句从DB缓冲区中读取了大量的信息;总缓冲区的典型特征:高逻辑读、高缓冲区缓存命中率(当它被一个选择性较差的索引驱动时)和高CPU使用率
***减少过渡使用缓冲区，可以使用分区和索引，并考虑SQL优化，避免过渡的表扫描
***15.4 总磁盘读表明SQL语句从存储中读取了大量的数据，而不是DB块缓冲区，过渡的存储读会导致性能问题
***减少过渡的存储读，可以使用分区和索引，并考虑SQL优化，避免过渡的全表扫描;内存充足的情况下，可以考虑增加DB缓冲区缓存
***总磁盘读的典型特征:高物理读、低缓存区命中率、低CPU使用率和IO等待时间
***如果存储读是数据库的一部分(在DSS或者数据仓库,全表扫描是其系统架构的自然结果)可以考虑移动数据到全闪存阵列
***15.5 总执行次数(Executions)高总执行数表明数据库中某些SQL是不正确的;大量执行语句通常被正确地重(chong)用,
***高执行次数和高逻辑读/物理读的语句是检查的候选对象，以确保他们在只需要执行一次时不会执行多次
***如果数据库中有过多的物理读和逻辑读，或过多的I/O等待时间，那么需要查看执行次数过多，且物理读和逻辑读高的SQL语句
***15.6 解析调用(Parse Calls)---当一个语句无论何时被用户或者进程执行时，不管SQL语句是否在SQL池中存在，都需要进行解析
***解析可以是硬解析或软解析
***如果Oracle在SQL池中找不到相同散列签名的SQL，那么Oracle会使用大量的递归SQL和所有其他的解析包来进行硬解析;如果在SQL池中找到了SQL，
那么只需要使用最小的递归进行软解析，以验证底层对象的用户权限;过多的解析调用通常伴随着过多的执行
***如果使用的是不安全的绑定变量(指绑定变量在peek的过程中，因为某些原因导致CBO认为这个值对应的执行计划不是最优的，所以会对这个SQL根据不同的值生成多个
版本的执行计划，那么语句就会被重新解析)
***15.7 可共享内存 提供了被重用SQL语句的信息，以及他们所使用的共享池中内存的数量，只有使用共享内存超过1,048,576字节的语句才会在报告中显示。
***通常较高消耗内存是由不良代码或过渡的多表关联的大SQL造成的----大语句会导致过渡的解析、递归和大量的CPU使用
***15.8 版本数 通常由多个相同模式数据库、不安全的绑定变量或者Oracle bug 引起的;在Oracle 9I 或者10G 会有一些BUG导致不安全的绑定变量产生多个版本
***多个版本在共享池会耗尽SQL内存空间，高版本数也可能导致过渡的解析
****小窍门:将隐含参数 _sqlexec_progression_cost 的值设置高于默认的1000，可以降低易受影响版本 ***
***15.9 集群等待时间 只有在RAC系统时，集群等待事件才会出现;在这一节中，进行大量跨界点互连传输的SQL会被列出;
***如果数据块太大，或每个服务器上的DB缓存都太小，或SQL使用了太多的表数据，就会出现高级别的块传输
***大量更新语句也可能出现在这里，因为更新需要在很多情况下对当前块进行块传输
****高级别的全局缓存类型的等待事件表明需要在本节查找有问题的SQL***
***16 实例活动统计 (Instance Activity Statistics)