AWR报表解读

---awr
----------报表头信息
报表的第一部门包含了数据库本身的信息，包括数据库的名称，ID，版本号以及主机等信息。
随后是快照的开始时间和结束时间，以及有多少活动会话的信息。
缓存尺寸部分显示了缓冲区缓存的值（初始化文件中的db_cache_size）;共享池的尺寸（shared_pool_size）;标准数据块的尺寸（db_block_size）;日志缓冲区（log_buffer）

-------------负载简档

提供了负载简档每一秒和每一个事物的统计信息。这是一个监控您的系统的吞吐量和负载变化的重要部分。
当系统的负载增加时，您将看到每一秒的数字会增大。当您将系统调整为最大效率时，每个事务的统计信息
中将显示较低的数字。
负载简档可以帮助识别负载正在执行的活动类型。
1.重做数据块的增加，快更改变得频繁，以及每次读操作%block的增加，这些意味这dml活动的增加。
2.当sql语句不是在共享池中运行时，就会出现硬分析。硬分析率超过100次/秒就意味这绑定变量的效率不高，应当使用cursor_sharing初始化参数，或者说明共享池的大小有问题。
3.当sql语句时在共享池中运行时，就会出现软分析。软分析率超过300次/秒就意味着应用程序的效率不高，语句被反复地执行，而不是对每个会话应只分析语句一次，以保证高效率。

-----------------实例的效率

Instance Efficiency信息展示了许多通用的命中率的信息。dba经常检测这些参数，以便可以通过和历史数据的比较来预警系统行为的显著变化。命中率时一个用来预警最近引入系统的普通潜在问题和特定潜在问题的极佳方法。
1.Buffer Nowait %低于99%：这是一个对特定缓冲区的请求的命中率，在内存中的该缓冲区应当立即可用。如果命中率下降，在buffer wait部分中将发现当前存在（热）数据块争用的现象。
2.Buffer Hit %:低于95%：这是一个对特定缓冲区的请求的命中率，并且缓冲区位于内存中，而无需物理磁盘的I/O操作。尽管原来时作为测量内存效率的少数几种方法之一，但它仍然时一个用于展示您所需的物理磁盘I/O效率的好方法，这将有益于进一步调查性能问题的原因。但是，如果您在访问时经常使用非选择性索引，
它将使您的命中率很高，这将导致有些dba作出认为系统系能很好的错误判断。当您有效地调整了您的sql语句，并在全系统范围内使用了高校的索引，这个问题不会经常遇到，并且命中率将时一个更佳性能的指示器。
（1）命中率稳定在95%，但有一天上升到99%，这时就应该查找糟糕的sql或导致大量逻辑读操作的索引（检查负载简档和首要缓存gets sql）
（2）命中率稳定在95%,但突然下降到45%，这时就应该查找导致大量物理读操作的糟糕的sql（检查首要物理读操作sql），这些物理读操作没有使用索引或索引被删除。
3.Library Hit %低于95%:较低的库命中率通常意味着sql语句被过早地推出了缓冲池（可能是因为缓冲池太小了）。较低的命中率还意味着没有使用绑定变量或者一些其他的问题造成sql没有被重用（在这种情况下，较小的共享池时唯一的权宜之计或许可以修复所引发的库闩锁问题）。尽管声称始终降低共享池来解决库缓存和共享池闩锁问题，但哦见过的大多数千兆字节系统都有以十亿字节为单位的共享池，也没有产生任何问题，因为他们解决了sql问题。您必须解决这个问题（使用绑定变量或者cursor_sharing）并确定共享池的合适尺寸。
4.在OLTP中的In-memory Sort %低于95%：在一个OLTP系统中，您一定不想做磁盘排序。设置初始化参数pga_aggregate_target(或者sort_area_size)可有效地解决该问题
5.Soft Parse %低于95%，正如负载简档中所说的，软分析低于80%意味着sql没有被重用。并需要作进一步调查
6.Latch Hit %:低于99%通常是个大问题：找到特定的闩锁可棒子您解决该问题

------------------共享池的统计信息

显示了正使用的共享池的百分比以及重复执行多次（根据需要）的sql语句的百分比。将该数据与库，分析和闩锁数据相结合，将可帮助您确定共享池的大小。                            Begin    End
Memory Usage %:                    28.37    29.17
% SQL with executions>1:    27.77    30.45
% Memory for SQL w/exec>1:    56.64    67.74
根据上面列表中的数据，在第二次快照时，有29.17%的共享池内存在用。共享池中语句只有30%执行的次数多于一次。说明应用程序内的共享游标需要进一步提高使用效率。

---------------5个首要等待事件
报表显示了五个最重要的等待事件，等待事件的全部列表以及后台的等待时间。标识主要等待事件将帮助您将调整的努力放在系统中最紧追的问题上。
1.db file scattered(分散的，散乱的) read
db file scattered read等待事件意味着等待与全表扫描或快速全索引扫描有关。因为全表扫描时放入内存中进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散步在缓冲区的缓存总。该指数的数量过大说明缺少索引或者限制使用索引。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当您看到这些等待时。需要通过检查来确定全表扫描是否有必需的。尝试将较小的表放入缓存中，避免反复读取他们。将数据定位在磁盘系统上，这些系统有更多磁盘缓存或由OS文件系统缓存缓冲。db_file_multilock_Read_count能够让 全表扫描更快（但它也会影响oracle完成更多扫描）。您也可以将表和索引分区，以便只扫描其中一部分。缓慢的文件I/O（缓慢的磁盘也会导致这些等待。）
2.db file sequential(连续读) read
db file sequential read 等待时间通常时指单一的数据块读操作（例如，索引的读取）该值过大说明表的连接顺序很糟糕，