内容发布更新时间 : 2024/7/1 16:05:46星期一 下面是文章的全部内容请认真阅读。
精品资料
? Memory Usage，说明在shared pool中，被使用的部分占shared pool总尺寸的百分
比。这个值应保持适中，(如85%）,如果太高，则会引起shared pool中的对象被刷出内存，从而导致sql语句的硬解析增加，太低则浪费内存； ? SQL with executions>1，执行次数大于1次的sql占总sql数的百分比，越大越好； ? Memory for SQL w/exec>1，在shared pool中执行次数大于1次的sql语句所消耗
的内存占shared pool的百分比
5) TOP5事件（Top 5 Timed Events）
这个部分也是AWR报告中非常重要的部分，从这里可以看出等待时间在前五位的是什么事件，基本上就可以判断出性能瓶颈在什么地方。通常，在没有问题的数据库中，CPU time总是列在第一个，其他几类重要影响性能的事件分析如下。
? 缓冲区忙(buffer busy)：当一个会话想要访问缓存中的某个块，而这个块正在被其它会
话使用时，将会产生该等待事件。这时候，其它会话可能正在从数据文件向缓存中的这个块写入信息，或正在对这个块进行修改。出现这个等待事件的频度不应大于1%。如果这个等待事件比较显著，则需要根据等待事件发生在缓存中的哪一块（如字段头部、回退段头部块、回退段非头部块、数据块、索引块等），采取相应的优化方法。 ? 文件分散读取(db file scattered read)：该等待事件通常与全表扫描有关。因为全表扫
描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。如果这个等待事件比较显著，可能说明对于某些全表扫描的表，没有创建索引或没有创建合适的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要。 ? 文件顺序读取(db file sequential read)：该等待事件通常与单个数据块相关的读取操作
有关。如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，或者可能不合适地使用了索引。对于大量事务处理、调整良好的系统，这一数值大多是很正常的，但在某些情况下，它可能暗示着系统中存在问题。应检查索引扫描，以保证每个扫描都是必要的，并检查多表连接的连接顺序。另外db_cache_size?也是这些等待出现频率的决定因素。 ? 队列(enqueue)：队列是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记
录中的数据，以避免两个人在同一时间更新同一数据。如果enqueue等待事件比较显著，则需要根据enqueue等待类型，采取相应的优化方法。 ? 闩锁释放(latch free)：latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于
保护系统全局区域(sga)中共享内存结构。该等待事件意味着进程正在等待其他进程已持有的latch。对于常见的latch等待通常的解决方法：1）share pool latch：在oltp应用中应该更多的使用绑定变量以减少该latch的等待。2）library cache latch：同样的需要通过优化sql语句使用绑定变量减少该latch的等待。
可编辑修改
精品资料
? 日志文件同步(log file sync)：这个等待事件是指当一个会话完成一个事务（提交或者回
滚数据）时，必须等待lgwr进程将会话的redo信息从日志缓冲区写到日志文件后，才能继续执行下去。这个等待事件的时间过长，可能是因为commit太频繁或者lgwr进程一次写日志的时间太长（可能是因为一次log io size太大），可调整_log_io_size。 ? wait for a undo record：数据库恢复 ?
read by other session ? READ BY OTHERS SESSIONS 的根本原因就是因为你某条SQL做了大量block的扫描, 我
猜想那条SQL至少要50万个逻辑读. 除了解决SQL问题,基本没有别的办法
6) Time Model Statistics
Statistic Name sql execute elapsed time DB CPU parse time elapsed hard parse elapsed time failed parse elapsed time sequence load elapsed time PL/SQL execution elapsed time hard parse (sharing criteria) elapsed time PL/SQL compilation elapsed time connection management call elapsed time hard parse (bind mismatch) elapsed time repeated bind elapsed time DB time Time (s) 85,698.49 26,832.02 369.05 324.19 109.55 62.49 17.78 7.54 1.42 0.49 0.13 0.12 86,229.43 % of DB Time 99.38 31.12 0.43 0.38 0.13 0.07 0.02 0.01 0.00 0.00 0.00 0.00 可编辑修改
精品资料 background elapsed time background cpu time 1,211.05 46.42 Sql execute elapsed time 数据库执行SQL总时间 parse time elapsed 解释SQL总时间
hard parse elapsed time 硬解释SQL的总时间 PL/SQL execution elapsed time pl/sql执行时间 DB CPU 用户占用CPU的总时间
failed parse elapsed time 遇到SQL解释时间
7) SQL统计（SQL Statistics）
AWR报告中还有一块对性能影响最大的指标，TOP SQL统计。本节按各种资源分别列出对资源消耗最严重的SQL语句，并显示它们所占统计期内全部资源的比例，提供给我们调优依据。
? SQL ordered by Elapsed Time： 记录了执行总和时间的SQL，记录的是监控范围内
该SQL的执行时间总和，需要综合分析CPU时间（CPU Time）和执行次数（Executions）才能得到单个SQL的代价。单次执行开销较大的SQL属于重点优化之列。 ? SQL ordered by CPU Time： 记录了执行占CPU时间总和时间最长的SQL，再CPU
消耗较大的系统中，重点优化此类SQL。 ? SQL ordered by Gets： 记录了执行占总buffer gets(逻辑IO)的SQL，查找总的缓冲
区获取比较高的SQL，并根据平均每次执行缓冲区获取的数量判断优化的余地有多大。优化这些SQL，有助于减少CPU开销以及数据缓冲池相关的闩锁竞争。 ? SQL ordered by Reads：记录了执行占总磁盘物理读(物理IO)的SQL，查找总的物理
读比较高的SQL，并根据平均每次执行物理读的数量判断优化的余地有多大。优化这些SQL，有助于减少I/O开销和CPU开销。 ? SQL ordered by Executions：记录了按照SQL的执行次数排序的SQL，执行次数多
的SQL也是需要重点优化，使sql语句中的子操作执行次数尽量少。
可编辑修改
精品资料
? SQL ordered by Parse Calls：记录了解析次数排序的SQL，避免出现硬解析，采用使
用绑定变量等方式。 ? SQL ordered by Sharable Memory：记录了SQL占用library cache的大小的SQL。 ? SQL ordered by Version Count：记录了SQL的打开子游标的SQL。 ? SQL ordered by Cluster Wait Time：记录了集群的等待时间的SQL。
8) IO Stats -->Tablespace IO Stats
Tablespace Reads Av Reads/s Av Rd(ms) Av Blks/Rd Writes Av Writes/s Buffer Waits Av Buf Wt(ms) SYSAUX UNDOTBS SYSTEM USERS TEMP TEST2 9,553 7,879 2,496 364 34 4 0 0 0 0 0 0 4.07 3.21 4.74 3.08 3.24 47.50 1.65 19,729 1.00 8,252 1.62 4,469 1.57 12.35 1.00 4 25 4 0 0 0 0 0 0 0 20 0 0 0 0 0.00 5.50 0.00 0.00 0.00 0.00 ? 1）可以找到具有频繁读写活动的表空间或数据文件，如果临时表空间的写入数量最高，说明排序太多太大； ? 2）从AVG BLKS/RD列可以看出，哪些表空间上经历了最多的全表扫描，如果值大于1，则应该将该值与初始化参数db_file_multiblock_read_count的值进行比较，如果他们越接近，说明在该表空间上进行的大部分是全表扫描； ? 3）检查AV RD(MS),该列表明I/O读的时间，值应该小于20ms，如果过大应该检查是否将读写很频繁的文件放在了同一个磁盘上 9) Segment Statistics
可编辑修改
精品资料
? 1）Segments by Logical Reads或Segments by Physical Reads 可以找到逻辑读或物理读比较
大的对象，并查找原因，是否可以通过创建新索引、或采用分区表等来降低对象的逻辑读以及物理读； ? 2）Segments by Row Lock Waits ，通过这个报表可以找到获得行级锁最严重的对象，需要跟开发
人员探讨解决方法；
? 3）Segments by ITL Waits ，这个报表可以标明获得ITL等待最严重的对象，如果发现了ITL等待
很严重的对象，则应该将对象的initrans参数设置为并发操作该对象的进程个数；
? 4）Segments by Buffer Busy Waits，获得buffer busy waits最严重的对象。在同一时刻只有一
个进程能够访问同一个数据块，其它进程必须等待。解决的关键是优化那些扫描了过多数据块的sql语句，减少他们要扫描的数据块。如果已经优化了sql语句，则可以考虑增大pctfree的值，从而减少一个数据块中能够包含的数据行数，从而将对象的数据行分部到更多的数据块里去。
10) Instance Activity Statistics 实例活动统计数据
1) 比较在内存中和磁盘中的排序量，如果磁盘排序太高就需要增加PGA_AGGREGATE_TARGET(或者旧
版本中增大SORT_AREA_SIZE)
可编辑修改