Oracle 生成AWR报表以及报表参数解读

目录

一、什么是 AWR？

二、如何使用AWR？

1、手工创建一个快照

2、手工删除指定范围的快照

3、修改采集时间和统计信息保留时间

4、生成报表

三、解读 AWR

1、报表头

2、负载

3、实例效率

4、TOP 等待事件

5、主机 CPU、实例 CPU

6、Cache Sizes

7、共享池统计信息

---

一、什么是 AWR？

AWR 全称叫 Automatic Workload Repository 自动负载信息库，AWR 是通过 对比两次快照(snapshot)收集到的统计信息，来生成报表数据，生成的报表包括 多个部分，通过 AWR 报告，DBA 可以容易地获知最近数据库的活动状态，数据库 的各种性能指标的变化趋势，最近数据库可能存在的异常，分析数据库可能存在 的性能瓶颈从而对数据库进行优化。  AWR 报告所有的数据来源于 AWR 视图，即 以 DBA_HIST_开头的所有系统表。AWR 在生成报告时，可以选择生成 TXT 或 HTML 两种格式的报告，相对来说，HTML 更利于阅读，而 TXT 的适用性更广。
1、  ash 占用的内存大小
ASH 的采集信息保存在内存中，在旧的信息被采样到 AWR 中后，可被新采集 的信息覆盖，重启oracle 后该信息被清除，查询分配给 ASH 的内存大小：
SQL>selectpool,name,bytes/1024/1024Fromv$sgastatwherenamelike
'%ASH%';
POOL      NAME      BYTES/1024/1024
-------------   -------------   ---------------
shared pool  ASH buffers          2
2、  mmon 进程与 mmnl 进程
快照由 MMON 的新的后台进程 (及其从进程) 以及 MMNL 后台进程自动地每隔 固定时间采样一次。MMON 进程负责执行多种和管理相关的后台任务，例如：
 当某个测量值 (metrics) 超过了预设的限定值 (threshold value) 后提 交警告
 创建新的 MMON 隶属进程 (MMON slave process) 来进行快照 (snapshot)  捕获最近修改过的 SQL 对象的统计信息
MMNL 进程负责执行轻量级的且频率较高的和可管理性相关的后台任务， 例如捕获会话历史信息，测量值计算等。
AWR 的采样工作由MMON 进程每个 1 小时执行一次，ASH 信息同样会被采样写 出到 AWR 负载库中。虽然 ASH buffer 被设计为保留 1 小时的信息，但很多时候 这个内存是不够的，当 ASH buffer 写满后，另外一个后台进程 MMNL 将会主动将 ASH 信息写出。
3、  SYSAUX 表空间
采样数据都存储在 SYSAUX 表空间中，并且以WRM$_* 和 WRH$_*的格式命名。

前一种类型存储元数据信息 (如检查的数据库和采集的快照) ，后一种类型保存 实际采集的统计数据。
SQL>selecttable_namefromdba_tableswheretable_namelike'WRM$%';

TABLE NAME
_
-----------------------
WRM$_WR_CONTROL
WRM$_SNAP_ERROR
WRM$_SNAPSHOT
WRM$_DATABASE_INSTANCE
WRM$_BASELINE
当 SYSAUX 表空间填满后，AWR 将自动覆盖掉旧的信息，并在警告日志中记录一 条相关信息：
ORA-1688:unabletoextendtableSYS.WRH$_ACTIVE_SESSION_HISTORY   partitionWRH$_ACTIVE_3533490838_1522by128intablespace
SYSAUX
4、采样频率和保留时间
通过查询视图 dba_hist_wr_control 或 (wrm$_wr_control) 来查询 AWR 的 采样频率和保留时间。默认为每 1 小时采样一次，采样信息保留时间为 8 天。
SQL>select*fromdba_hist_wr_control;

DBID SNAP_INTERVAL RETENTION  TOPNSQL
----   -------------   -----------   ----------
1148 +00000 00:1  +00008 00:0 DEFAULT
SQL>selectDBID,SNAP_INTERVAL,SNAPINT_NUM,RETENTIONfrom
wrm$_wr_control;

DBID SNAP INTERVAL
_

SNAPINT NUM RETENTION
_

----------   ------------------   -----------   --------------------
1160732652 +00000 01:00:00.0     3600 +00008 00:00:00.0

5、采样数据量
由于数据量巨大，把所有 ASH 数据写到磁盘上是不可接受的。一般是在写到 磁盘的时候过滤这个数据，写出的数据占采样数据的 10%，写出时通过        direct-path insert 完成，尽量减少 日志生成，从而最小化数据库性能的影响。
6、初始化参数 statistics_level

AWR 的行为受到参数 statistics_level 的影响，这个参数有三个值：
basic：awr 统计的计算和衍生值关闭，只收集少量的数据库统计信息   typical：默认值，只有部分的统计收集，典型监控 oracle 数据库的行为
all：所有可能的统计都被捕捉，并且有操作系统的一些信息，如需要更多的 sql 诊断信息的时候才使用。
show parameter statistics_level

二、如何使用AWR？

AWR 由 oracle 自动产生，但是也可以通过 dbms_workload_repository 包来 手工创建、删除和修改。可以使用desc 命令查看该包中的过程。下面介绍几个 常用的：

1、手工创建一个快照

通过dbms_workload_repository.create_snapshot过程。通过
dba_hist_snapshot 视图查看刚刚创建的snapshots 信息
查看当前已经产生的awr 快照
selectmax(snap_id)fromdba_hist_snapshot;
手工生成一个 awr 快照
execdbms_workload_repository.create_snapshot ();
查询验证创建的快照
selectmax(snap_id)fromdba_hist_snapshot;
selectsnap_idfromdba_hist_snapshot;

2、手工删除指定范围的快照

删除 Snapshots 使用 dbms_workload_repository 包的另一个过程，      drop_snapshot_range，该过程在执行时可以通过指定 snap_id 的范围的方式一 次删除多个 Snapshots，例如：
selectmin(snap_id),max(snap_id)fromdba_hist_snapshot;
selectcount(0)fromdba_hist_snapshotwheresnap_idbetween7509and
7518;
SQL>selectdbidfromv$database;
SQL>begin
dbms_workload_repository.drop_snapshot_range(

low_snap_id=>2,
high_snap_id=>2,
dbid=>1601792006);
end;
/
selectmin(snap_id),max(snap_id)fromdba_hist_snapshot;

3、修改采集时间和统计信息保留时间

参数名称：RETENTION 、INTERVAL 、TOPNSQL 、DBID
通过修改 retention 参数可以修改 awr 信息在 sysaux 表空间的保留期限。 默认的是七天,最小值是一天。如果把 retention 设置为零, 自动清除就关闭了。 如果awr 发现 sysaux 空间不够,将删除最老部分的快照来重新使用这些空间。同 时, 在警告日志中记录一条警告。
通过修改 interval 参数可以修改 awr 信息的采样频率。最小的值是 10 分钟, 默认是 60 分钟.典型的值是 10,20,30,60,120 等等。把 interval 设为 0 则关闭 自动捕捉快照。如将收集间隔时间改为 90 分钟一次，并且保留 9 天时间 (注： 单位都是为分钟) ：
SQL>select*fromdba_hist_wr_control;

DBID SNAP_INTERVAL    RETENTION      TOPNSQL
----------   ------------------   --------------------------   -----------
1160732652 +00000 01:00:00.0 +00008 00:00:00.0      DEFAULT
SQL>exec                                                        dbms_workload_repository.modify_snapshot_settings(interval=>90, retention=>9*24*60);
SQL>SELECT*fromdba_hist_wr_control;

DBID SNAP_INTERVAL    RETENTION     TOPNSQL
----------   -------------------   -------------------------   -----------
1160732652 +00000 01:30:00.0  +00009 00:00:00.0     DEFAULT

4、生成报表

awr 报表生成机制,可以对存储在workload 资料库的统计产生汇总报表，通过运行$ORACLE_HOME/rdbms/admin 目录中的 awrrpt.sql 完成报表生成。这个脚 本显示所有的现有 AWR 快照并请求两个特定的快照作为时间间隔边界。产生两种 类型的输出：文本格式和默认的 HTML 格式。运行脚本必须 select any dictionary 权限。
1、需指明要生成 html，还是 text 格式
2、选择快照的天数:输入天数和最近的快照,可以使用 dba_hist_snapshot 来查 看 nap_id。
3、开始 snap_id 和终止 snap_id，报表产生的时间间隔。
4、报告文件名称。
awrrpt.sql 脚本显示指定快照 id 范围的诊断信息；awrrpti.sql 脚本与  awrrpt.sql 类似，唯一的不同就是在 awrrpti.sql 脚本中，可以指定数据库 ID 和实例 ID (作为参数) ，@$ORACLE_HOME/rdbms/admin/awrddrpt.sql 可以生成 对比报告。
运行该脚本以查看报表，从而对 AWR 的报表功能有一个直观的了解。 生成标准统计报表
sql>@$ORACLE_HOME/rdbms/admin/awrrpt.sql
Enter value for report_type: html
Enter value for num_days: 2
此处需指定要读取多少天内的快照信息！
Enter value for begin_snap: 7331
Enter value for end_snap: 7355
Enter value for report_name:
指定报告文件名，默认会根据前面输入的 snap_id 生成一个文件名，可以使用默认文件名。

三、解读 AWR

一个 AWR 性能报告至少需要 2 个 AWR snapshot 性能快照才能生成 ( 注意这2 个快照时间，实例不能重启过，否则指定这 2 个快照生成 AWR 性能报告会报错)

1、报表头

Session 总数和平均每个 session 打开多少 cursor
DB TIME= 所有前台 session 花费在 database 调用上的总和时间：
DB Time 不包括 Oracle 后台进程消耗的时间 (数据库运算(非后台进程)和等待 (非空闲等待)时间) 。
◾注意是前台进程 foreground sessions
◾ 包括 CPU 时间、IO Time、和其他一系列非空闲等待时间，别忘了 cpu on queue time
DB Time 描绘了数据库总体负载，但要和 elapsed time 逝去时间结合其他来。

Average Active Session      AAS= DB time/Elapsed Time

DB Time =60 min ，  Elapsed Time =60 min   AAS=60/60=1 负载一般 DB Time= 1min , Elapsed Time= 60 min  AAS= 1/60 负载很轻
DB Time= 60000 min，Elapsed Time= 60 min  AAS=1000  负载重，系统 hang

如果 DB Time 远远小于 Elapsed 时间，说明数据库比较空闲，db time 就是 记录的服务器花在数据库运算 (非后台进程) 和等待 (非空闲等待) 上的时间。 db time= cpu time + wait time (不包含空闲等待) ，从 awr report 的 Elapsed

time 和 DB Time 能大概了解 db 的负载。
对于批量系统，数据库的工作负载总是集中在一段时间内，如果快照周期不 在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得 出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表 性能问题的时间段。

2、负载

显示数据库负载概况，与基线数据比较才具有更多的意义，如果每秒或每事 务的负载变化不大，说明应用运行比较稳定。
单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确” 的值，然而 Logons 大于每秒 1~2 个、Hard parses 大于每秒 100、全部 parses  超过每秒 300，表明可能有争用问题。
了解系统整体负载状况，如每秒中的事务数/语句数，每秒/每事务物理读写 次数(Physical Reads/Writes), 逻辑读写次数(Logical Reads/Writes)，SQL 语句的解析(Parse)，特别是硬解析次数等。

Redo size：每秒产生的日志大小(单位字节)，标志数据变更频率, 数据库 的繁重与否。redo size 可以用来估量 update/insert/delete 的频率，大的 redo size 往往对 lgwr 写 日志，和 arch 归档造成 I/O 压力，  Per Transaction 可以 用来分辨是大量小事务，  还是少量大事务。

Logical reads： 每秒/每事务逻辑读的块数,平均每秒产生逻辑读的 block 数。
单位：次数*块数，逻辑读消耗 CPU，主频和CPU 核数都很重要，逻辑读高则 DB CPU 往往高，也往往可以看到 latch: cache buffer chains 等待。大量 OLTP 系统可以高达几十乃至上百Gbytes。
logical reads=consistent gets+db block gets

Block changes：每秒/每事务修改的块数，描绘数据变化频率

Physical reads：每秒/每事务物理读的块数，物理读消耗 IO 读，体现在 IOPS 和吞吐量等不同纬度上；但减少物理读可能意味着消耗更多 CPU。好的存储 每 秒物理读能力达到几 GB，例如 Exadata.这个 physical read 包含了 physical reads cache 和 physical reads direct
Physical writes：每秒/每事务物理写的块数，单位：次数*块数，主要是 DBWR 写 datafile，也有 direct  path  write。  dbwr 长期写慢会导致定期 log file switch(checkpoint no complete) 检查点无法完成的前台等待。这个 physical
write 包含了 physical writes direct +physical writes from cache User calls：每秒/每事务用户 call 次数

Parses：SQL 解析的次数，每秒解析次数，包括 soft parse 和 hard parse

Hard parses：硬解析的次数，硬解析太多，说明 SQL 重用率不高。每秒产生的 硬解析次数, 每秒超过 100 次，就可能说明你绑定变量使用的不好，也可能是共 享池设置不合理。一系列的等待,Cursor pin s on X，  library cache: mutex X ，
latch: row cache objects /shared pool……………..。硬解析最好少于每秒
20 次
W/A MB processed :单位MB  W/A workarea  workarea中处理的数据数量,结合 In-memory Sort%，  sorts (disk) PGA Aggr一起看

Logons：每秒/每事务的登录的次数

Executes：每秒/每事务 SQL 执行次数，反应执行频率

Rollback：回滚次数，反应回滚频率，但是这个指标不太精确,每事务的回滚率。 看回滚率是不是很高，过高说明有很多无效的操作，会带来undo block 块的竞 争。

Transactions：每秒事务数，，反映数据库任务繁重与否。是数据库层的 TPS， 可以看做压力测试或比对性能时的一个指标，孤立看无意义

3、实例效率

Oracle关键指标的内存命中率及其它数据库实例操作的效率。各指标都应接近100%，除了： execute to parse (70%以上)和parse cpu to parse elapsed。如果不符合，基本可以确定 系统存在性能问题；但是如果反过来，即都符合，也不能说明系统完全正常，还要看实际情 况。
本节需要根据应用的特点判断各项是否合适。如：在一个使用直接读执行大型 并行查询的 DSS 环境，20%的Buffer Hit Ratio 是可以接受的，而这个值对于一 个 OLTP 系统是完全不能接受的。根据 Oracle 的经验，对于 OLTP 系统，Buffer Hit Ratio 理想应接近 100%为好。
Buffer Nowait session 申请一个buffer 不等待的次数比例。需要访问buffer
时立即可以访问的比率，BufferNowait 的这个值一般需要大于 99%。否则可能
存在争用。
buffer hit 表示进程从内存中找到数据块的比率，监视这个值是否发生重大 变化比这个值本身更重要。对于一般的 OLTP 系统，反应物理读和缓存命中间的 纠结，但这个指标即便99% 也不能说明物理读等待少了，通常，如果此值低于 80%，应该给数据库分配更多的内存。
调整重要的参数，小于 90%可能要加 db_cache_size。一个高的命中率，不一定 代表这个系统的性能是最优的，比如大量的非选择性的索引被频繁访问，就会造 成命中率很高的假相，但是一个比较低的命中率，一般就会对这个系统的性能产 生影响，需要调整。
不合理的 db_cache_size，或者在 ASMM 和 AMM 下都可能因为 db_cache_size 过小引起大量的 db file sequential /scattered read 等待事件； 曾经遇到过 因为大量硬解析导致 ASMM 下 shared pool 大幅度膨胀，而 db cache 相应缩小 的例子，本来没有的物理读等待事件都产生了 。
library hit 表示 Oracle 从 Library Cache 中检索到一个解析过的 SQL 或  PL/SQL 语句的比率， 当应用程序调用 SQL 或存储过程时，Oracle 检查 Library Cache 确定是否存在解析过的版本，如果存在，Oracle 立即执行语句；如果不存 在，Oracle 解析此语句，并在Library Cache 中为它分配共享SQL 区。低的 library hit ratio 会导致过多的解析，增加 CPU 消耗，降低性能。
如果 libraryhitratio 低于 90%，可能需要调大 sharedpool 区。合理值：>95% ，
维护这个指标的重点是保持 shared pool 共享池有足够的Free Memory，且没有 过多的内存碎片。显然过小的 shared pool 可用空间会导致 library cache    object 被 aged out 换出共享池。此外保证 SQL 语句绑定变量和游标可以共享也 是很重要的因素。
数据来源 V$librarycache 的 pins 和 pinhits。

Execute to Parse：是语句执行与解析的比例，如果要 SQL 重用率高，则这个
比例会很高。该值越高表示一次解析后被重复执行的次数越多。计算公式为：
ExecutetoParse=100* (1-Parses/Executions)。

在 oracle 中解析往往是执行的前提工作，但是通过游标共享可以解析一次执 行多次，  执行解析可能分成多种场景：
1、hard coding => 硬编码代码 硬解析一次 ，执行一次，  则理论上其执行解 析比为 1:1 ，则理论上 Execute to Parse =0 极差，且 soft parse 比例也为 0%

2、绑定变量但是仍软解析=>软解析一次，执行一次，这种情况虽然比前一种好 但 是执行解析比(这里的parse，包含了软解析和硬解析)仍是 1:1，理论上Execute to Parse =0 极差，但是 soft parse 比例可能很高

3、使用静态 SQL、动态绑定、session_cached_cursor、open cursors 等技术实 现的 解析一次，执行多次，执行解析比为 N:1，则 Execute to Parse= 1- (1/N) 执行次数越多 Execute to Parse 越接近 100% ，这种是我们在 OLTP 环境中喜闻 乐见的！

soft parse% 反映了软解析率，  而软解析在 oracle 中仍是较昂贵的操作， 我们希望的是解析 1 次执行 N 次，如果每次执行均需要软解析，那么虽然 soft parse%=100% 但是 parse time 仍可能消耗大量 DB TIME。
Execute to Parse 和 soft parse% 都很低，说明可能没有绑定变量，而如
果 soft parse%接近 99%而 Execute to Parse 不足 90%，则说明执行解析比低， 需要通过静态 SQL、动态绑定、session_cached_cursor、open cursors 等技术 减少软解析。
Parse CPU to Parse Elapsd：反映了快照内解析 CPU 时间和总的解析时间的比
值(Parse CPU Time/ Parse Elapsed Time)；解析实际运行时间/(解析实际运行
时间+解析中等待资源时间)，越高越好。计算公式为：ParseCPUtoParse

时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为 100%，意味着 CPU 等待时间为 0，没有任何等待。若该指标水平很低，那么说明在整个解析过 程中 实际在 CPU 上运算的时间是很短的，而主要的解析时间都耗费在各种其他 非空闲的等待事件上了(如 latch:shared pool,row cache lock 之类等)
Redo NoWait 表示在 LOG 缓冲区获得 BUFFER 的未等待比例。如果太低 (可参 考 90%阀值) ，考虑增加 LOG BUFFER。 当 redo buffer 达到 1M 时，就需要写到
redo log 文件，所以一般当 redo buffer 设置超过 1M，不太可能存在等待 buffer 空间分配的情况。
In-memorySort：在内存中排序的比率，如果过低说明有大量的排序在临时表 空间中进行。考虑调大 PGA(10g)。如果低于95%，可以通过适当调大初始化参数

PGA_AGGREGATE_TARGET 或者 SORT_AREA_SIZE 来解决，注意这两个参数设置作用 的范围时不同的，SORT_AREA_SIZE 是针对每个 session 设置的，             PGA_AGGREGATE_TARGET 则时针对所有的 sesion 的。
In-memory Sort% =  sort(memory) / ( sort(disk)+ sort(memory) ) Soft Parse：是 AWR 中另一个重要的解析指标，软解析的百分比
(softs/softs+hards) ，近似当作 sql 在共享区的命中率，太低则需要调整应
用，使用绑定变量。  sql 在共享区的命中率，小于<95%,需要考虑绑定，如果低 于 80%，那么就可以认为 sql 基本没有被重用
若该指标很低，那么说明了可能存在剧烈的hard parse 硬解析，大量的硬解 析会消耗更多的 CPU 时间片并产生解析争用(此时可以考虑使用               cursor_sharing=FORCE)；  理论上我们总是希望 Soft Parse % 接近于 100%， 但 并不是说 100%的软解析就是最理想的解析状态，通过设置                   session_cached_cursors 参数和反复重用游标我们可以让解析来的更轻量级， 即通俗所说的利用会话缓存游标实现的软软解析(soft soft parse)。
Latch Hit：Latch 是一种保护内存结构的锁，可以认为是 SERVER 进程获取访 问内存数据结构的许可。要确保 Latch Hit>99%，否则意味着 Shared Pool latch
争用，可能由于未共享的 SQL，或者 Library Cache 太小，可使用绑定变更或调 大 SharedPool 解决。要确保>99%，否则存在严重的性能问题。当该值出现问题 的时候，我们可以借助后面的等待时间和 latch 分析来查找解决问题。
willing-to-wait latch 闩 申请不要等待的比例
Non-Parse CPU ：SQL 实际运行时间/(SQL 实际运行时间+SQL 解析时间)，太
低表示解析消耗时间过多。计算公式为：%Non-ParseCPU
=round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小，表示解析消耗的
CPU 时间过多。与 PARSE_CPU 相比，如果 TOT_CPU 很高，这个比值将接近 100%， 这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询 的工作。
上述指标对OLTP的要求:

80%以上 90%以上 95%以上
98%以上

%Non-Parse CPU
Buffer Hit%, In-memory Sort%, Soft Parse%
Library Hit%, Redo Nowait%, Buffer Nowait%
Latch Hit%
 

4、TOP 等待事件

基于等待事件的调优，好比马路上 100 辆汽车的行驶记录表，上车用了几分 钟，  红灯等了几分钟，拥堵塞了几分钟。丰富的等待事件以足够的细节来描绘 系统运行的性能瓶颈。通常，在没有问题的数据库中，CPU time 总是列在第一个。    Waits :该等待事件发生的次数，  对于 DB CPU 此项不可用
Times :该等待事件消耗的总计时间，单位为秒，  对于 DB CPU 而言是前台进程 所消耗 CPU 时间片的总和，但不包括Wait on CPU QUEUE
Avg Wait(ms):该等待事件平均等待的时间，  实际就是 Times/Waits，单位 ms，
对于 DB CPU 此项不可用
% Total Call Time，该等待事件占总的 call time 的比率
% Total Call Time  =  time for each timed event / total call time
其中，total call time  =  total CPU time + total wait time for non-idle events
Wait Class: 等待类型，通过 select distinct wait_class from v$event_name; 查看等待类型
db file scattered read:Avg wait time 应当小于 20ms,如果数据库执行全表扫 描或者是全索引扫描会执行 Multi block I/O ，此时等待物理 I/O 结束会出现 此等待事件。
db file sequential read:单块读等待是一种最为常见的物理 IO 等待事件，这 里的 sequential 指的是将数据块读入到相连的内存空间中(contiguous memory space)，而不是指所读取的数据块是连续的。db file sequential read 等待事 件 Avg wait time 平均单次等待时间应当小于 20ms

当我们调优时，总希望观察到最显著的效果， 因此应当从这里入手确定我们 下一步做什么。例如：
如果‘buffer busy wait’是较严重的等待事件，我们应当继续研究报告中 Buffer Wait 和 File/Tablespace IO 区的内容，识别哪些文件导致了问题。
如果最严重的等待事件是 I/O 事件，我们应当研究按物理读排序的SQL 语句 区以识别哪些语句在执行大量 I/O，并研究Tablespace 和 I/O 区观察较慢响应 时间的文件。
如果有较高的 LATCH 等待，就需要察看详细的LATCH 统计识别哪些LATCH 产 生的问题。

5、主机 CPU、实例 CPU

CPU资源利用情况，CPU可能指：
1、  OS级的User%，Sys%，  Idle%
2、  DB所占OS CPU资源的Busy%
3、DB CPU又可以分为前台所消耗的CPU和后台所消耗的CPU
分析上面的图片，我们可以得出下面的结论：
  OS级的User%，Sys%，Idle%：
OS级的%User为75.4，%Sys为2.8，%Idle为21.2，所以%Busy应该是 100-21.1=78.8。
  DB所占OS CPU资源的Busy%
DB 占了 OS CPU 资源的 69.1，%Busy CPU 则可以通过上面的数据得到：  %Busy

CPU = %Total CPU/(%Busy) * 100 = 69.1/78.8 * 100 = 87.69，和报告的 87.7 相吻合。

6、Cache Sizes

显示 SGA 中每个区域的大小，可用来与初始参数值比较。
shared pool 主要包括 library cache 和 dictionary cache。library cache 用来存储最近解析(或编译)后SQL、PL/SQL 和 Java classes 等。dictionary cache 用来存储最近引用的数据字典。
发生在 library cache 或 dictionary cache 的 cache miss 代价要比发生在 buffer cache 的代价高得多。 因此 shared pool 的设置要确保最近使用的数据 都能被 cache。
如果 shared pool 一直收缩，则在 shrink 过程中一些 row cache 对象被 lock 住，可能导致前台 row cache lock 解析等待。如果 shared pool 一直在增长， 那说明 shared pool 原有大小不足以满足需求，可能是大量硬解析。

7、共享池统计信息

Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用
率，应该稳定在 75%-90%间，如果太小，表明共享池设置过大，说明 SharedPool
有浪费，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。而如 果高于 90，会使共享池外部的组件老化，如果 SQL 语句被再次执行，这将使得
SQL 语句被硬解析，说明共享池中有争用， 内存不足。 在一个大小合适的系统中，共享池的使用率将处于 75%到略低于90%的范围内.
SQL with executions>1：复用的 SQL 占总的 SQL 语句的比率，即执行次数大 于 1 的 sql 比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过 多 SQL 解析。
Memory for SQL w/exec>1：执行次数大于 1 的 SQL 消耗内存的占比。这是与 不频繁使用的SQL 语句相比，频繁使用的SQL 语句消耗内存多少的一个度量。这 个数字将在总体上与% SQL with executions>1 非常接近，除非有某些查询任务 消耗的内存没有规律。在稳定状态下，总体上会看见随着时间的推移大约有   75%~85%的共享池被使用。