awr报告

AWR

http://www.askmaclean.com/archives/performance-tuning-oracle-awr.html

诸如 Statspack 和 AWR (automatic workload repository）报告之类的 Oracle 实用 工具给数据库管理员（DBA）提供了有关数据库执行时间快照的详细信息。这些快照提供了 关于等待事件、闩锁（latch）、存储 I/O 吞吐量和消耗时间的统计数据，以及关于内存和 SQL 活动的各种视图。
对内存、I/O 和 SQL 性能特征的统计和观察非常重要，可以帮助确定数据库是否能够最 优地运行。

获取当前默认的自动抓取 AWR 快照的配置参数值

column awr_snapshot_retention_period format a40 SELECT EXTRACT(day from retention) || ':' ||

EXTRACT(hour from retention) || ':' ||
EXTRACT (minute from retention) awr_snapshot_retention_period, EXTRACT (day from snap_interval) *24*60+
EXTRACT (hour from snap_interval) *60+
EXTRACT (minute from snap_interval) awr_snapshot_interval FROM dba_hist_wr_control;

set linesize 120
column SNAP_INTERVAL format a30 column RETENTION format a30 select * from dba_hist_wr_control;

默认情况下每 60 分钟抓取一次 AWR 快照，快照保存 8 天

设置抓取 AWR 快照的参数

执行如下的命令，设置自动抓取 AWR 快照的参数：
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
retention => 44640,
interval => 30,
topnsql => 50
); END;
/

这段代码将配置默认数据库的 AWR：
数据保留时间，从默认的 8 天改为 31 天；
快照的收集间隔从 60 分钟调整到 20 分钟； 每个类别收集前 50 条 SQL 语句。

set linesize 120
column SNAP_INTERVAL format a30 column RETENTION format a30 select * from dba_hist_wr_control;

Note Begin

如果要配置指定的数据库的 AWR，可以指定 DBID： BEGIN

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
retention => 44640,
interval => 15,
topnsql => 50,
dbid => 2742440278
); END;
/

收集 DBID 为 2742440278 的数据库的快照。

------其他参数修改

DBMS_WORKLOAD_REPOSITORY.AWR_SET_REPORT_THRESHOLDS(
top_n_events IN NUMBER DEFAULT NULL, top_n_files IN NUMBER DEFAULT NULL, top_n_segments IN NUMBER DEFAULT NULL, top_n_services IN NUMBER DEFAULT NULL, top_n_sql IN NUMBER DEFAULT NULL, top_n_sql_max IN NUMBER DEFAULT NULL, top_sql_pct IN NUMBER DEFAULT NULL, shmem_threshold IN NUMBER DEFAULT NULL, versions_threshold IN NUMBER DEFAULT NULL);

exec DBMS_WORKLOAD_REPOSITORY.AWR_SET_REPORT_THRESHOLDS(top_n_sql=>30);

Note End

手工抓取 AWR 快照

执行如下的命令，可以在任意时间抓取 AWR 快照：

begin
dbms_workload_repository.create_snapshot();
end;
/

或者执行如下的命令，可以在任意时间抓取 AWR 快照：

exec dbms_workload_repository.create_snapshot();

可 以 为 dbms_workload_repository.create_snapshot() 指 定 一 个 参 数 flush_level ( TYPICAL 或 ALL ，前者是默认值）：
如果使用 TYPICAL ，会保存每个分类的前 30 个 top SQL 语句；
如果指定 ALL，会保存前 100 个 top SQL 语句。

exec dbms_workload_repository.create_snapshot(flush_level=>'ALL'); exec dbms_workload_repository.create_snapshot(flush_level=>'TYPICAL');

查看 AWR 快照

查看当前的快照情况
select SNAP_ID,DBID,INSTANCE_NUMBER from DBA_HIST_SNAPSHOT
order by SNAP_ID;

抓取
begin
dbms_workload_repository.create_snapshot();
end;
/

再次查看快照的情况
select SNAP_ID,DBID,INSTANCE_NUMBER from DBA_HIST_SNAPSHOT
order by SNAP_ID;

6 / 45

查看当前 AWR 快照占有了多少空间

SELECT space_usage_kbytes FROM v$sysaux_occupants
WHERE occupant_name = ‘SM/AWR’;

手动删除 AWR 快照 删除一定范围的快照

查看快照的情况
select SNAP_ID,DBID,INSTANCE_NUMBER from DBA_HIST_SNAPSHOT
order by SNAP_ID;

执行下面的命令，删除 SNAP_ID=1 到 SNAP_ID=3 的快照：
exec dbms_workload_repository.drop_snapshot_range(low_snap_id =>1,high_snap_id
=>3,dbid => 2742440278);

或者

begin
dbms_workload_repository.drop_snapshot_range( low_snap_id =>1,
high_snap_id =>3,
dbid => 2742440278);
end;
/

再次查看快照的情况
select SNAP_ID,DBID,INSTANCE_NUMBER from DBA_HIST_SNAPSHOT
order by SNAP_ID;

删除特定的某个快照

首先生成几个快照：
exec dbms_workload_repository.create_snapshot(); exec dbms_workload_repository.create_snapshot(); exec dbms_workload_repository.create_snapshot(); exec dbms_workload_repository.create_snapshot();

查看母亲 AWR 快照的情况：
select SNAP_ID,DBID,INSTANCE_NUMBER from DBA_HIST_SNAPSHOT
order by SNAP_ID;

假如要删除快照 6 begin
dbms_workload_repository.drop_snapshot_range( low_snap_id =>6,
high_snap_id =>6,
dbid => 2742440278);
end;
/

再次查看快照的情况
select SNAP_ID,DBID,INSTANCE_NUMBER from DBA_HIST_SNAPSHOT
order by SNAP_ID;

AWR 基线

通常情况下，AWR 快照不会无限期地保存下去，经过一段时间后 AWR 快照就会被删除 掉。
我们可以把指定时间段的快照可以标记成基线（ baseline ），也就是说 AWR 基线是由 多个连续的 AWR 快照组成。AWR 快照被标记为基线之后，就不会被删除。
AWR 基线可以用来做对比：可以在系统运行良好的时候保存了一段时间的基线。在性 能问题发生时，可以捕获 AWR 快照与 AWR 基线的时间段做对比，比较两者的差异，从而 更容易找出问题所在。

AWR 基线有两种：
 固定基线（fixed baseline）：由静态的开始快照 ID 和静态的结束快照 ID 限定的一 组连续快照。可以根据需要创建多个基线。
 移动窗口基线（moving window baseline ）：指定时间内（特别是以天为单位）的 一组连续快照并且以最近的快照作为结束。每个数据库都有一个移动窗口基线作为 数据引擎的自适应阈值。

管理 AWR 固定基线

创建 AWR 固定基线

set linesize 120
select SNAP_ID,DBID,INSTANCE_NUMBER from DBA_HIST_SNAPSHOT
order by SNAP_ID;

使用快照 ID 范围为 21~25 的 AWR 快照创建 AWR 基线，并将快照命名为 TEST，该基 线 30 天后过期：

begin dbms_workload_repository.create_baseline( start_snap_id => 21,
end_snap_id => 25, baseline_name => ‘TEST’, expiration => 30);
end;
/

如果不指定 expiration 参数（默认值为 NULL），表示创建的 AWR 基线永远不过期。

查看 AWR 基线的情况

使用下面的语句可以查看名字为 TEST 的 AWR 基线的情况：
set linesize 120
column START_SNAP_TIME format A30 column END_SNAP_TIME format A30
SELECT start_snap_id, start_snap_time, end_snap_id, end_snap_time FROM dba_hist_baseline
WHERE baseline_name = ‘TEST’
AND baseline_type = ‘STATIC’;

显示 AWR 基线的相关度量值

dbms_workload_repository 包提供了 select_baseline_metric 函数用来显示基线（同样也 对移动窗口基线适用）相关的度量值。

SELECT metric_name, metric_unit, minimum, average, maximum FROM table(dbms_workload_repository.select_baseline_metric(‘TEST’)) ORDER BY metric_name;

重命名 AWR 基线

begin dbms_workload_repository.rename_baseline(
old_baseline_name => ‘TEST’, new_baseline_name => ‘TEST1’
);
end;

/

12 / 45

删除 AWR 基线

删除时要指定基线的名字。如果使用 cascade 参数，将一并删除建立基线的 AWR 快照。

select SNAP_ID,DBID,INSTANCE_NUMBER from DBA_HIST_SNAPSHOT
order by SNAP_ID;

begin dbms_workload_repository.drop_baseline( baseline_name => ‘TEST1’,
cascade => TRUE
);
end;
/

select SNAP_ID,DBID,INSTANCE_NUMBER from DBA_HIST_SNAPSHOT
order by SNAP_ID;

管理 AWR 移动窗口基线

设置 AWR 移动窗口基线的窗口大小

设置窗口时间为 10 天（注意不允许将窗口时间设置为超过快照的保存时间）

exec dbms_workload_repository.modify_baseline_window_size(window_size => 10);

查看 AWR 移动窗口基线的窗口大小

set linesize 120
column BASELINE_NAME format A30 SELECT baseline_name, moving_window_size FROM dba_hist_baseline
WHERE baseline_type = ‘MOVING_WINDOW’;

生成 AWR 报告

生成 AWR 报告的 Oracle 官方脚本

-----相关脚本说明
•awrrpt.sql：生成指定快照区间的统计报表；
•awrrpti.sql：生成指定数据库实例，并且指定快照区间的统计报表；
•awrsqlrpt.sql：生成指定快照区间，指定 SQL 语句(实际指定的是该语句的 SQLID)的统计报 表；
•awrsqrpi.sql：生成指定数据库实例，指定快照区间的指定 SQL 语句的统计报表；
•awrddrpt.sql：指定两个不同的时间周期，生成这两个周期的统计对比报表；
•awrddrpi.sql：指定数据库实例，并指定两个的不同时间周期，生成这两个周期的统计对比 报表；

–1.生成单实例 AWR 报告：
@$ORACLE_HOME/rdbms/admin/awrrpt.sql

–2.生成 Oracle RAC AWR 报告：
@$ORACLE_HOME/rdbms/admin/awrgrpt.sql

–3.生成 RAC 环境中特定数据库实例的 AWR 报告:
@$ORACLE_HOME/rdbms/admin/awrrpti.sql

–4.生成 Oracle RAC 环境中多个数据库实例的 AWR 报告的方法：
@$ORACLE_HOME/rdbms/admin/awrgrpti.sql

–5.生成 SQL 语句的 AWR 报告：
@$ORACLE_HOME/rdbms/admin/awrsqrpt.sql

–6.生成特定数据库实例上某个 SQL 语句的 AWR 报告：
@$ORACLE_HOME/rdbms/admin/awrsqrpi.sql

----生成 AWR 时段对比报告
–7.生成单实例 AWR 时段对比报告
@$ORACLE_HOME/rdbms/admin/awrddrpt.sql

–9.生成 Oracle RAC AWR 时段对比报告
@$ORACLE_HOME/rdbms/admin/awrgdrpt.sql

–10.生成特定数据库实例的 AWR 时段对比报告
@$ORACLE_HOME/rdbms/admin/awrddrpi.sql

–11.生成 Oracle RAC 环境下特定（多个）数据库实例的 AWR 时段对比报告
@$ORACLE_HOME/rdbms/admin/awrgdrpi.sql

• awrrpt.sqI ：标准默认的脚本，单实例、两个数据集的增量报告。
• awrrpti.sql ：标准特定实例的脚本，两个数据集的增量报告。
• awrsqrpt.sql ： 默认实例中单个特定 SQL 语句的报告。
• awrsqrpti.sql ： 一组快照 ID 内，单个特定实例中特定 SQL 语句的报告．
• awrddpt.sqI ：默认实例的两个间隔的比较报告。
• awrddrpi.sql ：特定实例的两段特定时间时隔的报告。
• awrgrpt.sql ： 默认 RAC 数据库中所有实例的全局报告．
• awrgdrpt.sql ：特定 RAC 数据库中所有实例的全局报告。 全局报告会收集 Oracle RAC 数据库中所有实例的基本统计数

解读 AWR 报告

解读 AWR 报告的要点

AWR 报告非常长，解读 AWR 报告要去繁从简，有选择的查看重点部分。一个比较好的 方法是，将有问题时候的 AWR 报告，对照系统正常时候的 AWR 报告，找出两者之间的差 异，进行解读。
阅读 AWR 报告，可以先分析系统的总体情况，找出问题的方向；之后才是深入具体的 情况。

系统总体情况方面，可以查看以下部分：
1）Load Profile：通过这一部分可以了解系统的整体负载状况
2）Instance Efficiency Percentages：这部分的指标，目标值都应接近 100%。查看这一部分， 可以很容易找到偏离目标的方向。

具体情况方面
1）Top 5 Timed Events：这里列出消耗时间最多的 5 个等待事件，每种等待说明，都表示一 种原因，如：db file sequential read 表示按索引访问出现等待，db file scattered reade 表示 全表扫描访问出现等待事件。
2）Top N SQL：根据时间消耗，内存消耗，物理 I/O 等排序，对相关 SQL 分析执行计划
3）如果是 RAC 环境，需要特别关注 RAC Statistic 中的相关指标
4）SGA PGA 分析
5）分析表空间、数据文件 I/O

一个 11gR2（11.2.0.3.0）的例子

AWR 报告头部

这是一个 Oracle RAC 系统中的第一个节点，有 2 个 CPU，每个 CPU16 核，物理内存应 该是 64GB，操作系统是 Linux。该 Oracle 服务器是 2016 年 8 月 10 日夜里 0 点 8 分启动的。

AWR 报告基于如下期间的 AWR 快照生成： 起始 Snap Id 为 21128；
结束 Snap Id 为 21129。
AWR 报告总结了这期间大概 1 小时的运行情况。
Note Begin
dbtime 的官方定义：
This statistics represents the total time spent in database calls and is an indicator of the total instance workload.
Dbtime 代表花费在数据库调用上的所有时间，是实例负载的总体度量。

It is calculated by aggregating the CPU and wait times of all sessions not waiting on idle wait events (non-idle user sessions).
dbtime=DB CPU+non-idle user sessions

大牛 TOM：
db time is the time spent in the database dbtime 是花费在数据库上的时间。

Note End

Report Summary (AWR 报告的总体部分)

Cache Sizes（数据库高速缓存的大小）

AWR 报告指出了 Oracle 数据库服务器的高速缓存大小：
Buffer Cache 大小是 2GB； Shared Pool 大小是 2GB；
Log Buffer 的大小大概是 10MB； Oracle 数据块的大小是 8KB

Load Profile（数据库负载去情况）

这一段，我们要关注 Logical reads、Physical reads、Physical writes，大量的逻辑读和物 理读意味着要关注 I/O 相关的问题。这个数据库的 AWR 报告表明，每秒钟有 52,573.9 个逻 辑读，每个事务有 5,603.0 个逻辑读；每秒钟有 9,837.5 个物理读，每个事务有 1,048.4 个物 理读。逻辑读和物理读都比较高！(需要进一步查找原因)

在这一段，我们还要关注 User calls、Parses、Hard parses、logons、Executes、Transactions。 这个数据库的 AWR 报告表明，每秒钟用户的调用是 434.9 次（比较繁忙），每秒钟有 45.6 次 parses，其中有 24.6 次是 hard parse。（在解析方面，有需要改进的地方！）每秒中执行了 152.6 条 SQL 语句（系统够忙的！）

Note Begin
User calls = User session Login +

Parsing within a session + Executions of sql’s/Cursors

Executes = (Sql’s execution)

Note End

Instance Efficiency Percentages (Target 100%) （实例效率）

这些指标，都应该尽可能地接近100%。这个数据库的AWR报告表明：
Soft Parse%只有46.09%（比较低！），表明系统的硬解析太多！（需要解决该问题） Execute to Parse%只有70.11%(比较低)，表明软软解析相对较少！
硬解析和软解析比较多！
Parse CPU to Parse Elapsd %是94.16%，表示解析过程中的事件等待时间只占%6
（貌似问题不大）
%Non-Parse CPU（在所有的DB CPU中，不是用于解析的CPU百分比）是91.62
如果该值比较低，表示很多时间用于解析操作了。
Library Hit%只有80.89%（比较低！）综合上面的原因，我们可以推测这个值较低的 原因，很可能是因为硬解析太多！

Note Begin

 软解析百分比（ Soft Parse %）
太低的话，表明有太高的硬解析！

 执行解析比（ Execute to Parse %）
Execute to Parse% = (l - Parses/Executions）* 100%
本例中： Parses=45.6 Executions=152.6
Execute to Parse% = ( 1 - Parses/Executions）* 100%
= ( 1 – 45.6/152.6 ) * 100% = 70.11%
以上数据可以从 AWR 报告的 Load Profile 中获取！

如果执行解析比偏小，说明解析(硬解析与软解析)的比例较大，快速解析（即软软解析、 无解析）较少！

参考 https://blog.csdn.net/leshami/article/details/49489631
硬解析：SQL 语句在 library cache 无缓存 软解析：SQL 语句在 library cache 找到了执行计划
软软解析：在 pga 内搜索 session cursor cache list 列表中找到对应的 SQL，无论软解析、还 是软软解析，都有解析这个操作。

要改善解析与执行的比率关系，就需要增加无解析的次数，无解析就是不再解析，为 SQL 绑定不同的变量，然后执行。这样做的前提就是：1、Session 不能断开；2、Session 执行过 解析过的 SQL 不要关闭；满足这两点就可以实现无解析。 可以通过提高 参数 session_cached_cursors 的值来改善执行解析比（execute to parse）

 解析CPU 时间和总解析时间比（ parse CPU to parse elapsed %)
如果该指标很低，说明在整个解析过程中，实际在CPU 上运算的时间很短，而主要的 解析时间都耗费在各种其他非空闲的等待事件上了（如latch:shared pool、row cache lock 之类等）

 %NON-PARSE CPU
表示在整个 DB CPU 中非 PARSE CPU 所占用的百份比。 越高表示用于解析的 CPU 越少，用于执行查询的 CPU 越多。
该值比较小表示解析使用的 DB CPU 时间多于语句执行的时间，也许系统存在解析问 题。

 In-emory Sort % 内存排序百分比
如果值偏低，需要增加 PGA 内存。

 Latch Hit%
闩锁命中率会告诉我们在闩锁上等待的时间。 如果我们经常在闩锁上自旋，这个值就会降低。

如果这个百分比很低，那么应查看：
那些绑定运行在某些 CPU 上的进程

与闩锁有关的问题。
 Buffer Nowait %和 Buffer Hit %

如果我们看到 Buffer Nowait %和 Buffer Hit % 很低（小于 95%），那么就需要调查数据块 缓冲区是否被正确使用，以及是否需要增加数据块缓冲区大小。

 Redo Nowait %
告诉我们重做缓冲区被利用的效率。 如果这个百分比很低，就需要对重做日志缓冲区和重做日志进行调优：
要么就是缓冲区就太小
要么就是有操作阻止重做日志以适当的方式被重用（很可能是没有足够多的 重组日志组）

Note End

Shared Pool Statistics

Memory Usage %：理想情况下，对于一个已经预热过的生产数据库，这个值应该在 80%左右
（或者说在 70%~90%之间）。如果太小，说明 Shared Pool 有浪费，而如果高于 90，说明共 享池中有争用，内存不足。

SQL with executions>1：执行次数大于 1 的 sql 比率。 如果此值太小，说明需要
在应用中更多使用绑定变量
采用 PL/SQL 封装应用 来避免过多 SQL 解析。

Memory for SQL w/exec>1：执行次数大于 1 的 SQL 消耗内存的占比。

Top 5 Timed Foreground Events

rac1 节点的

rac2 节点的

DB CPU：通常，在没有问题的数据库中，DB CPU 是列在第一个。

direct path read：
传统读取数据的方式是服务器进程通过读取磁盘，然后把数据加载到 SGA 共享内存中， 这样后面的进程就可以通过 SGA 共享内存访问这些数据，不用再通过缓慢的磁盘读取来完 成。
direct path read 读取数据块方式，是指服务器进程直接读取数据文件，不经过 buffer cache，这种方式读取的数据块会加载到服务器进程的 PGA 内中当中，不会进入 buffer cache 中。
11G 之前的 direct path read 主要用于并行查询中，此等待事件的三个参数 p1,p2,p3 分 别代表：file#：文件号，first block#：读取的起始块号，block count：以 first block 为起点， 连续读取的物理块数。
11G 之后，direct path read 不仅可用于并行查询，在符合某些条件后，串行的全表扫描 也可以利用 direct path read 方式来完成。
（因为本系统（oracle 11g）是 OLTP，不适合启用并行，因此可以推断是全表串行扫 描！）

db file sequential read：这表明是单块读取（索引读）引起的问题。 解决方法：

 增加更多的 Database Buffer Cache
将单块读的时间降低到 5ms 或者更低（优化磁盘阵列或者采用全闪存阵列）

db file scattered ·read：这表明是全表或全索引扫描引起的问题。 解决方法：
通过增加索引来减少全表扫描
（数据仓库）通过采用分区来减少扫描的数据量
采用更大的缓存，将表或者索引缓存的内存
提高磁盘系统的 IO 速度（降低到 5ms，甚至更低）

，当 db file sequential read 或 db file scattered ·read 成为重要的等待时，DBA 需要查看 AWR 报告的 SQL 部分，找出有过高逻辑或物理读的 TOP SQL 语句，进行 SQL 语句调优。 显然，如果同一条 SQL 语句多次出现在 AWR 报告 SQL 部分的多个子节中时，就应该对该 条 SQL 语句进行调优。

log file sync
log file parallel write log file sequential write log file single write
log file switch completion
这些等待事件在 TOP 5 等待事件列表中占主导地位，表明出现日志文件压力(重做日志）。 在采取适当的行动之前，必须确保等待是真正来自于 I/O 相关的问题，而不是诸如归档日志 记录之类的问题。
解决方法：
 增大 redo log 缓冲区
分离 redo log 文件和数据文件、控制文件、归档日志文件
采用更快的存储

Host CPU 和 Memory 的统计

Host CPU 部分指出：
系统有 2 个 CPU，一共有 32 个 core；
报告期间的平均负载大概是 2（2 个进程在运行，平均负载值应该小于 CPU 核数） 用户态占用 CPU 2.1%
内核态占用 CPU 0.3%
因为 I/O 等待占有 CPU 3.1% CPU 总体是空闲的 97.5%

Instance CPU 部分指出：
实例只使用了主机大概 2.2%的 CPU。在使用主机的 2.2%CPU 中，有效利用了 86.3%，用 于数据库的处理。
因为数据库中没有资源组（Resource Group），所以资源管理器（Resource Manager） 使用的 CPU 百分比为零（不需要管理资源）。

Memory 统计部分指出： 主机的总内存是 64GB， SGA 分配了 4523.8MB， PGA 分配了 1051.7MB
SGA 和 PGA 一共使用了系统 8.77 的内存

RAC Statistics

http://www.askmaclean.com/archives/rac-awr-statistics.html Oracle RAC AWR 指标含义

http://blog.itpub.net/30126024/viewspace-2113551/ AWR_RAC 的一些指标解读

RAC 有 2 个实例。

全局缓存负载概要显示了监控期间全局缓存的压力情况：只使用了 1000Mbps(可以转 换为 125MB/s)互联处理能力的 1180.45KB/s

Buffer access - remote cache %的值为 0.20%，表示只有少量的块（0.20%）来自另外一个 RAC 实例。

需要注意接收到的全局缓存块（Global Cache blocks received）与发送的全局缓存块
（Global Cache blocks served）数量，应该大致相等。

要求数据尽可能通过处于不同节点的实例数据库缓冲区高速缓存来获取（目标 100%， 本分析实例中，从本地缓冲区获取了 99.18%，从远程节点的缓冲区获取了 0.2%），而不是从 磁盘读取（本分析实例中仅有 0.62%的数据从硬盘读取）

另一个可能出现问题的迹象是 DBWR 融合写（DBWR Fusion Writes)过多（本例没有出 现这种情况）。融合写应该只用于缓存替换，这是一个不常见的操作。如果融合写过多，则 表示可能有不适当的数据库块缓存区域、过多的检查点、过度的提交，或者三者的组合。

Global Cache and Enqueue Services - Workload Characteristics

rac1

rac2

需要密切注意不同的块服务时间：如果在互连过程中为一个块服务的时间超过了从磁盘 读取数据的时间，那么互连将成为一个瓶颈，而不是一个好处。下面是两个节点的情况：

可以看出比从物理磁盘读出来需要的 5 毫秒要小。 注意刷新值（flush values），通常不应该超过 3ms。
在大多数情况下，全局队列计时（enqueue timing）数字应该小于 2 到 3ms。如 Oracle 文档中所述， 如果它们接近 20ms，那么全局字典的 GES (global enqueue sevice ）部分存 在严重的问题。本分析实例无这方面的问题（如下所示）。

Cluster Interconnect

时间模型统计

此节显示了各种类型的数据库处理任务所占用的 CPU 时间。 如果解析时间和硬解析时间的值很接近，那么就是产生了过度的硬解析。

显然本例硬解析也偏高！

操作系统统计数据

这一块，主要看用户态 2.09%、内核态 0.27%、空闲 97.48%、I/O 等待 3.11%
这个例子从总体上看，系统处于正常的状态（轻载状态）。

前台等待事件

前台进程是用户或应用程序级的进程。

read by other session：
read by other session 等待事件通常表示块太大或延迟太大，从而导致争用。 如果看到 read by other session 是主要的等待事件之一，那么查看 AWR 报告中的
Segments by x 部分已确认哪些表和索引正在被大量使用。可以考虑将这些段移到一个小于 默认块大小的表空间，比如 4KB 或 2KB ，或者降低存储延迟（用更好的存储阵列），以减少 这种争用．

后台等待事件

后台等待事件，是由 Oracle 进程堆栈中众多后台进程生成的等待。 DBWR、LGWR、 SMON、PMON 等，所有这些都会产生后台等待事件．
由于这部分内容，是按照事件的名字进行排序，因此需要进行搜索，找出重要的事件！

服务相关统计数据

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

•Complete List of SQL Text

Instance Activity Statistics 实例活动统计

•Instance Activity Stats

•Instance Activity Stats - Absolute Values

•Instance Activity Stats - Thread Activity

IO Stats

•IOStat by Function summary

•IOStat by Filetype summary

•IOStat by Function/Filetype summary

•Tablespace IO Stats

•File IO Stats

Buffer Pool Statistics

参考：

Note Begin

Note End

http://www.cnblogs.com/lYng/p/9442041.html

参考：
https://blog.csdn.net/qq_40687433/article/details/78960764

https://blog.csdn.net/hanbowu/article/details/43673329

https://www.cnblogs.com/wang-xiaohui/articles/4877275.html

http://www.askmaclean.com/archives/performance-tuning-oracle-awr.html

https://blog.csdn.net/elvis_lfc/article/details/52326148