ORACLE ASH/AWR 性能分析

一、WHY——为什么会出现ASH和AWR？ 1. 10g之前

用户的连接将产生会话，当前会话记录保存在v$session中；处于等待状态的会话会被复制一份放在v$session_wait中。当该连接断开后，其原来的连接信息在v$session和v$session_wait中就会被删除。这是10g之前的状况。

2. v$session_wait_history与ASH

若是一个普通的会话（我是指没有大量地耗费资源），则对于性能调整来说无足轻重。但若该会话在活动时大量占用了资源（比如：CPU，内存，I/O等），该会话信息的丢失，将无法评测当时的系统瓶颈究竟是什么。令DBA高兴的是，oracle10g中保留下了v$session_wait中的这些信息。

在10g中新出现了一个视图：v$session_wait_history。这个视图保存了每个活动session在v$session_wait中最近10次的等待事件。但这对于一段时期内的数据库性能状况的监测是远远不够的，为了解决这个问题，在10g中还新添加了一个视图：v$active_session_history。这就是ASH（active session history）。

典型的情况下,为了诊断当前数据库的状态，需要最近的五到十分钟的详细信息。然而，由于记录session的活动信息是很费时间和空间的，ASH采用的策略是：保存处于等待状态的活动session的信息，每秒从v$session_wait中采样一次，并将采样信息保存在内存中。

3. AWR

注意，ASH的采样数据是保存在内存中。而分配给ASH的内存空间是有限的，当所分配空间占满后，旧的记录就会被覆盖掉；而且数据库重启后，所有的这些ASH信息都会消失。这样，对于长期检测oracle的性能是不可能的。在Oracle10g中，提供了永久保留ASH信息的方法，这就是AWR（auto workload repository）。

由于全部保存ASH中的信息是非常耗费时间和空间的，AWR采用的策略是：每小时对v$active_session_history进行采样一次，并将信息保存到磁盘中，并且保留7天，7天后旧的记录才会被覆盖。这些采样信息被保存在视图wrh$_active_session_history中。而这个采样频率（1小时）和保留时间（7天）是可以根据实际情况进行调整的，这就给DBA们提供了更加有效的系统监测工具。

AWR永久地保存系统的性能诊断信息，由SYS用户拥有。一段时间后，你可能想清除掉这些信息；有时候为了性能诊断，你可能需要自己定义采样频率来获取系统快照信息。Oracle 10g在包dbms_workload_repository中提供了很多过程，通过这些过程，你可以管理快照并设定基线(baselines)。

4. 小结

这样，我们就知道了ASH和AWR产生的原因和功能。ASH保存了系统最新的处于等待的会话记录，可以用来诊断数据库的当前状态；而AWR中的信息最长可能有1小时的延迟，所以其采样信息并不能用于诊断数据库的当前状态，但可以用来作为一段时期内数据库性能调整的参考。

对于这些视图间的继承关系，eygle给出了一个关系图：

图1 各个视图的层次

其中视图dba_hist_active_sess_history是wrh$_active_session_history和其他几个视图的联合展现，通常通过这个视图进行历史数据的访问。

二、WHAT——什么是AWR？

现在我们稍微详细地了解一下刚才所说内容。

1. ash占用的内存大小

ASH的采集信息保存在内存中，在旧的信息被采样到AWR中后，可被新采集的信息覆盖，重启oracle后该信息被清除。分配给ASH的内存大小可以查询到：

SQL> select pool, name, bytes/1024/1024 From v$sgastat where name like '%ASH %';

POOL NAME BYTES/1024/1024
------------- ------------- ---------------
shared pool ASH buffers 2

2. AWR更正

为了便于描述和理解，在第一部分中，我们说AWR就是保存ASH中的信息。

其实，AWR记录的信息不仅是ASH，还可以收集到数据库运行的各方面统计信息和等待信息，用以诊断分析。

AWR的采样方式是，以固定的时间间隔为其所有重要的统计信息和负载信息执行一次采样，并将采样信息保存在AWR中。

可以这样说：ASH中的信息被保存到了AWR中的视图wrh$_active_session_history中。ASH是AWR的真子集。

3. mmon进程与mmnl进程

快照由一个称为 MMON 的新的后台进程（及其从进程）以及MMNL后台进程自动地每隔固定时间采样一次。我们先来看一下10g的概念指南中对这两个新增加的后台进程的介绍：

MMON进程负责执行多种和管理相关（manageability-related）的后台任务，例如：

• 当某个测量值（metrics）超过了预设的限定值（threshold value）后提交警告
• 创建新的 MMON 隶属进程（MMON slave process）来进行快照（snapshot）
• 捕获最近修改过的 SQL 对象的统计信息

MMNL进程负责执行轻量级的且频率较高的和可管理性相关的后台任务，例如捕获会话历史信息，测量值计算等。

AWR的采样工作由MMON进程每个1小时执行一次，ASH信息同样会被采样写出到AWR负载库中。虽然ASH buffer被设计为保留1小时的信息，但很多时候这个内存是不够的，当ASH buffer写满后，另外一个后台进程MMNL将会主动将ASH信息写出。

4. SYSAUX表空间

这些采样数据都存储在SYSAUX表空间中，并且以WRM$_* 和 WRH$_*的格式命名。前一种类型存储元数据信息（如检查的数据库和采集的快照），后一种类型保存实际采集的统计数据。

SQL> select table_name from dba_tables where table_name like 'WRM$%';

TABLE_NAME

-----------------------

WRM$_WR_CONTROL

WRM$_SNAP_ERROR

WRM$_SNAPSHOT

WRM$_DATABASE_INSTANCE

WRM$_BASELINE

当SYSAUX表空间满后，AWR将自动覆盖掉旧的信息，并在警告日志中记录一条相关信息：

ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_3533490838_1522 by 128 in tablespace SYSAUX

5. 采样频率和保留时间

可以通过查询视图dba_hist_wr_control或（wrm$_wr_control）来查询AWR的采样频率和保留时间。默认为每1小时采样一次，采样信息保留时间为7天。

SQL> select * from dba_hist_wr_control;

DBID SNAP_INTERVAL RETENTION TOPNSQL
---- ------------- ----------- ----------
1148 +00000 00:1 +00007 00:0 DEFAULT

SQL> select DBID, SNAP_INTERVAL, SNAPINT_NUM, RETENTION from wrm$_wr_control;

DBID SNAP_INTERVAL SNAPINT_NUM RETENTION
---------- ------------------ ----------- --------------------
1160732652 +00000 01:00:00.0 3600 +00007 00:00:00.0

6. 采样数据量

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

7. 初始化参数statistics_level

AWR的行为受到参数STATISTICS_LEVEL的影响。这个参数有三个值：

BASIC：awr统计的计算和衍生值关闭.只收集少量的数据库统计信息.

TYPICAL：默认值．只有部分的统计收集.他们代表需要的典型监控oracle数据库的行为.

ALL : 所有可能的统计都被捕捉. 并且有操作系统的一些信息.这个级别的捕捉应该在很少的情况下,比如你要更多的sql诊断信息的时候才使用.

三、HOW——如何使用AWR？

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

1. 手工创建一个快照

SQL> select count(*) from wrh$_active_session_history;

COUNT(*)

----------

317

SQL> begin

2 dbms_workload_repository.create_snapshot();

3 end;

4 /

PL/SQL 过程已成功完成。

SQL> select count(*) from wrh$_active_session_history;

COUNT(*)

----------

320

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

SQL> select * from wrh$_active_session_history where snap_id = 96;

SNAP_ID DBID INSTANCE_NUMBER SAMPLE_ID SAMPLE_TIME

---------- ---------- --------------- ---------- ----------------------------

96 1160732652 1 236930 06-10月-07 11.26.04.562 上午

96 1160732652 1 236930 06-10月-07 11.26.04.562 上午

96 1160732652 1 236930 06-10月-07 11.26.04.562 上午

SQL> begin

2 dbms_workload_repository.drop_snapshot_range(low_snap_id => 96, high_snap_id => 96, dbid => 1160732652);

3 end;

4 /

PL/SQL 过程已成功完成。

SQL> select * from wrh$_active_session_history where snap_id = 96;

未选定行

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

PROCEDURE MODIFY_SNAPSHOT_SETTINGS

参数名称 类型 输入/输出默认值?

------------------------------ ----------------------- ------ --------

RETENTION NUMBER IN DEFAULT

INTERVAL NUMBER IN DEFAULT

TOPNSQL NUMBER IN DEFAULT

DBID NUMBER IN DEFAULT

通过修改retention参数可以修改awr信息的保留期限。默认的是七天,最小的值是一天。如果把retention设置为零,自动清除就关闭了.如果awr发现sysaux空间不够,它通过删除那些最老部分的快照来重新使用这些空间.同时,也会给dba发一条警告,告诉sysaux空间不够了（在警告日志中）.

通过修改interval参数可以修改awr信息的采样频率。最小的值是10分钟,默认的是60分钟.典型的值是10,20,30,60,120等等。把interval设为0则关闭自动捕捉快照.如将收集间隔时间改为30 分钟一次。并且保留5天时间（注：单位都是为分钟）：

SQL> select *from dba_hist_wr_control;

DBID SNAP_INTERVAL RETENTION TOPNSQL

---------- ------------------ -------------------------- -----------

1160732652 +00000 01:00:00.0 +00007 00:00:00.0 DEFAULT

SQL> exec dbms_workload_repository.modify_snapshot_settings(interval=>30, retention=>5*24*60);

PL/SQL 过程已成功完成。

SQL> SELECT *from dba_hist_wr_control;

DBID SNAP_INTERVAL RETENTION TOPNSQL

---------- ------------------- ------------------------- -----------

1160732652 +00000 00:30:00.0 +00005 00:00:00.0 DEFAULT

SQL>

4. 设置基线

基线（baseline）是一种机制,这样你可以在重要时间的快照信息集做标记。一个基线定义在一对快照之间,快照通过他们的快照序列号识别.每个基线有且只有一对快照。

一次典型的性能调整实践从采集量度的基准线集合、作出改动、然后采集另一个基准线集合开始。可以比较这两个集合来检查所作的改动的效果。在 AWR 中，对现有的已采集的快照可以执行相同类型的比较。

假定一个名称为 apply_interest 的高度资源密集的进程在下午 1:00 到 3:00 之间运行，对应快照 ID 95 到 98。我们可以为这些快照定义一个名称为 apply_interest_1 的基准线：

SQL> select *From dba_hist_baseline;

未选定行

SQL> select * from wrm$_baseline;

未选定行

SQL> exec dbms_workload_repository.create_baseline(95, 98, 'apply_interest_1');

PL/SQL 过程已成功完成。

这一操作将快照从 95 到 98 编号，作为上面指定的基准线的一部分。查看现有的基准线：

SQL> select *from dba_hist_baseline;

DBID BASELINE_ID BASELINE_NAME START_SNAP_ID START_SNAP_TIME END_SNAP_ID END_SNAP_TIME

---------- ----------- ------------------------- ------------- ------------------------------------- ----------- ------------

1160732652 1 apply_interest_1 95 06-10月-07 11.00.05.375 上午 98 06-10月-07 01.44.58.062 下午

SQL> select *from wrm$_baseline;

DBID BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID

---------- ----------- ---------------------------- ------------- -----------

1160732652 1 apply_interest_1 95 98

SQL>

在一些调整步骤之后，我们可以创建另一个基准线 — 假设名称为 apply_interest_2，然后只为那些与这两条基准线相关的快照比较量度。

SQL> exec dbms_workload_repository.create_baseline(92, 94, 'apply_interest_2');

PL/SQL 过程已成功完成。

像这样把快照分隔在仅仅几个集合中有助于研究调整对于性能量度的影响。您可以在分析之后使用 drop_baseline() 来删除基准线；快照将保留（也可级联删除）。此外，当清除例程开始删除旧的快照时，与基准线相关的快照不会被清除，从而允许进行进一步的分析。

5. 删除基线

如果要删除一个基准线:

SQL> exec dbms_workload_repository.drop_baseline(baseline_name=>'apply_interest_1', cascade=>false);

PL/SQL 过程已成功完成。

SQL> select *from wrh$_active_session_history where snap_id in (95,96,97,98);

SNAP_ID DBID INSTANCE_NUMBER SAMPLE_ID SAMPLE_TIME

---------- ---------- --------------- ---------- -------------------------------

95 1160732652 1 235360 06-10月-07 10.56.29.872 上午

95 1160732652 1 235230 06-10月-07 10.54.19.857 上午

95 1160732652 1 233130 06-10月-07 10.19.19.478 上午

95 1160732652 1 232830 06-10月-07 10.14.18.859 上午

95 1160732652 1 232250 06-10月-07 10.04.38.481 上午

97 1160732652 1 238600 06-10月-07 12.33.08.420 下午

97 1160732652 1 238600 06-10月-07 12.33.08.420 下午

97 1160732652 1 238600 06-10月-07 12.33.08.420 下午

97 1160732652 1 238600 06-10月-07 12.33.08.420 下午

97 1160732652 1 238600 06-10月-07 12.33.08.420 下午

97 1160732652 1 238600 06-10月-07 12.33.08.420 下午

SNAP_ID DBID INSTANCE_NUMBER SAMPLE_ID SAMPLE_TIME

---------- ---------- --------------- ---------- -------------------------------

97 1160732652 1 238420 06-10月-07 11.50.55.686 上午

97 1160732652 1 238230 06-10月-07 11.47.45.687 上午

98 1160732652 1 239140 06-10月-07 01.42.00.976 下午

98 1160732652 1 239140 06-10月-07 01.42.00.976 下午

98 1160732652 1 239140 06-10月-07 01.42.00.976 下午

98 1160732652 1 239140 06-10月-07 01.42.00.976 下午

98 1160732652 1 239140 06-10月-07 01.42.00.976 下午

98 1160732652 1 239130 06-10月-07 01.27.04.161 下午

98 1160732652 1 239130 06-10月-07 01.27.04.161 下午

98 1160732652 1 239130 06-10月-07 01.27.04.161 下午

已选择21行。

SQL> exec dbms_workload_repository.drop_baseline(baseline_name=>'apply_interest_2', cascade=>true);

PL/SQL 过程已成功完成。

SQL> select *from wrh$_active_session_history where snap_id in (92,93,94);

未选定行

SQL>

6. 生成报表

awr有个报表生成机制,可以对存储在workload资料库的统计产生汇总报表。这个分析对一段时间的统计做的。这个报表生成机制很像statspack。

可以使用脚本awrrpt.sql或awrrpti.sql来查看AWR报告（非常类似statspack中的spreport.sql），这两个脚本都在目录$ORACLE_HOME/rdbms/admin中。Awrrpt.sql脚本可以显示指定快照id范围的诊断信息，报告可以保存为文本文件或HTML文件；awrrpti.sql脚本与awrrpt.sql类似，唯一的不同就是在awrrpti.sql脚本中，你可以指定数据库ID和实例ID（作为参数）。报告包括如下诊断信息：

[1] Report summary
[1] Wait events statistics
[1] SQL statistics
[1] Instance activity statistics
[1] I/O statistics
[1] Buffer pool statistics
[1] Advisory statistics
[1] Wait statistics
[1] Undo statistics
[1] Latch statistics
Segment statistics
[1] Dictionary cache statistics
[1] Library cache statistics
[1] SGA statistics
[1] Resource limit statistics
[1] init.ora parameters

通过运行$ORACLE_HOME/rdbms/admin目录中的awrrpt.sql脚本，AWR的功能可以立即通过它从采集的统计数据和量度中生成的报表得到最好的说明。这个脚本显示所有的现有AWR快照并请求两个特定的快照作为时间间隔边界。它产生两种类型的输出：文本格式（类似于Statspack报表的文本格式但来自于AWR信息库）和默认的HTML格式（拥有到部分和子部分的所有超链接），从而提供了非常用户友好的报表。

运行这个脚本必须要select any dictionary权限.这个脚本提示你输入选项如怎么和在哪里生成这个报表:

*首先,你需要指明你要生成html还是text格式的
*要选择快照的天数:输入天数,和你最近的快照,可选的,你可以使用dba_hist_snapshot表来看你要用哪个snap_id.
*开始snap_id和终止snap_id,这个快照对定义你的报表产生的时间间隔.
*文件名称,报告写的用户指定的文件.

现在运行该脚本以查看报表，从而对AWR的报表功能有一个直观的了解。

SQL> @D:/oracle/product/10.2.0/db_1/RDBMS/ADMIN/awrrpt.sql

Current Instance

~~~~~~~~~~~~~~~~

DB Id DB Name Inst Num Instance

----------- ------------ -------- ------------

1160732652 ORCL 1 orcl

Specify the Report Type

~~~~~~~~~~~~~~~~~~~~~~~

Would you like an HTML report, or a plain text report?

Enter 'html' for an HTML report, or 'text' for plain text

Defaults to 'html'

输入 report_type 的值:

Type Specified: html

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host

------------ -------- ------------ ------------ ------------

* 1160732652 1 ORCL orcl YUECHAOTIAN

Using 1160732652 for database Id

Using 1 for instance number

Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Entering the number of days (n) will result in the most recent

(n) days of snapshots being listed. Pressing without

specifying a number lists all completed snapshots.

输入 num_days 的值: 4

Listing the last 4 days of Completed Snapshots

Snap

Instance DB Name Snap Id Snap Started Level

------------ ------------ --------- ------------------ -----

orcl ORCL 81 04 10月 2007 07:24 1

83 05 10月 2007 13:34 1

84 05 10月 2007 16:19 1

85 05 10月 2007 17:00 1

86 05 10月 2007 18:00 1

87 05 10月 2007 19:10 1

88 05 10月 2007 20:00 1

89 05 10月 2007 21:00 1

90 05 10月 2007 22:00 1

91 05 10月 2007 23:00 1

95 06 10月 2007 11:00 1

97 06 10月 2007 13:27 1

98 06 10月 2007 13:44 1

99 06 10月 2007 14:00 1

100 06 10月 2007 14:30 1

101 06 10月 2007 15:00 1

102 06 10月 2007 15:30 1

Specify the Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

输入 begin_snap 的值: 100

Begin Snapshot Id specified: 100

输入 end_snap 的值: 102

End Snapshot Id specified: 102

Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is awrrpt_1_100_102.html. To use this name,

press to continue, otherwise enter an alternative.

输入 report_name 的值:

Using the report name awrrpt_1_100_102.html

……（省略结果）

End of Report

Report written to awrrpt_1_100_102.html

SQL>

AWR报告日常分析

　如何分析：

* 在看awr报告的时候，我们并不需要知道所有性能指标的含义，就可以判断出问题的所在，这些性能指标其实代表了oracle内部实现，对oracle理解的越深，在看awr报告的时候，对数据库性能的判断也会越准确

* 在看性能指标的时候，心里先要明白，数据库出现性能问题，一般都在三个地方，io，内存，cpu，这三个又是息息相关的（ps：我们先假设这个三个地方都没有物理上的故障），当io负载增大时，肯定需要更多的内存来存放，同时也需要cpu花费更多的时间来过滤这些数据，相反，cpu时间花费多的话，有可能是解析sql语句，也可能是过滤太多的数据，到不一定是和io或内存有关系了

* 当我们把一条sql送到数据库去执行的时候，我们要知道，什么时候用到cpu，什么时候用到内存，什么时候用到io

1. cpu：解析sql语句，尝试多个执行计划，最后生成一个数据库认为是比较好的执行计划，不一定是最优的，因为关联表太多的时候，数据库并不会穷举所有的执行计划，这会消耗太多的时间，oracle怎么就知道这条数据时你要，另一个就不是你要的呢，这是需要cpu来过滤的
2. 内存：sql语句和执行计划都需要在内存保留一段时间，还有取到的数据，根据lru算法也会尽量在内存中保留，在执行sql语句过程中，各种表之间的连接，排序等操作也要占用内存
3. io：如果需要的数据在内存中没有，则需要到磁盘中去取，就会用到物理io了，还有表之间的连接数据太多，以及排序等操作内存放不下的时候，也需要用到临时表空间，也就用到物理io了

这里有一点说明的是，虽然oracle占用了8G的内存，但pga一般只占8G的20%，对于专用服务器模式，每次执行sql语句，表数据的运算等操作，都在pga中进行的，也就是说只能用1.6G左右的内存，如果多个用户都执行
多表关联，而且表数据又多，再加上关联不当的话，内存就成为瓶颈了，所有优化sql很重要的一点就是，减少逻辑读和物理读

如何生成awr报告：

* 1：登陆对应的数据库服务器
2：找到oracle磁盘空间（d:oracle\product\10.2.0\db_1\RDBMS\Admin)
3：执行cmd-cd d:回车
4: cd d:oracle\product\10.2.0\db_1\RDBMS\Admin 回车
5：sqlplus 用户名/密码@服务连接名(例：sqlplus carmot_esz_1/carmot@igrp)
6：执行@awrrpt.sql 回车

第一步输入类型： html
第二步输入天数： 天数自定义（如1，代表当天，如果2，代表今天和昨天。。。）
第三步输入开始值与结束值：（你可以看到上面列出的数据，snap值）
这个值输入开始，与结束
第四步输入导出表的名称：名称自定义 回车
第五步，由程序自动导完。

第六：到d:oracle\product\10.2.0\db_1\RDBMS\Admin 目录下。找到刚才生成的文件。 XXXX.LST文件

具体分析过程：

* 在分析awr报告之前，首先要确定我们的系统是属于oltp，还是olap（数据库在安装的时候，选择的时候，会有一个选项，是选择oltp，还是olap）
对于不同的系统，性能指标的侧重点是不一样的，比如，library hit和buffer hit，在olap系统中几乎可以忽略这俩个性能指标，而在oltp系统中，这俩个指标就非常关键了

* 首先要看俩个时间
Elapsed: 240.00 (mins) 表明采样时间是240分钟，任何数据都要通过这个时间来衡量，离开了这个采样时间，任何数据都毫无疑义
DB Time: 92,537.95 (mins) 表明用户操作花费的时候，包括cpu时间喝等待时间，也许有人会觉得奇怪，为什么在采样的240分钟过程中，用户操作时间竟然有92537分钟呢，远远超过了
采样时间，原因是awr报告是一个数据的集合，比如在一分钟之内，一个用户等待了30秒，那么10个用户就等待了300秒，对于cpu的话，一个cpu处理了30秒，16个cpu就是4800秒，这些时间都是以累积的方式记录在awr报告中的。

再看sessions，可以看出连接数非常多

* 为了对数据库有个整体的认识，先看下面的性能指标

1. Buffer Nowait 说明 在从内存取数据的时候，没有经历等待的比例，期望值是100%
2. Buffer Hit 说明从内存取数据的时候，buffer的命中率的比例，期望值是100%，但100%并不代表性能就好，因为这只是一个比例而已，举个例子，执行一条 sql语句，# 执行计划是需要取10000个数据块，结果内存中还真有这10000个数据块，那么比例是100%，表面上看是性能最高的，还有一个执行计划是需要500 个数据块，内存中有250个，另外250个需要在物理磁盘中取，
这种情况下，buffer hit是50%，结果呢，第二个执行计划性能才是最高的，所以说100%并不代表性能最好
3. Library Hit 说明sql在Shared Pool的命中率，期望值是100%
4. Execute to Parse 说明解析sql和执行sql之间的比例，越高越好，说明一次解析，到处执行，如果parse多，execute少的话，还会出现负数，因为计算公式是100*（1-parse/execute）
5. Parse CPU to Parse Elapsd 说明在解析sql语句过程中，cpu占整个的解析时间比例，，期望值是100%，说明没有产生等待，需要说明的是，即使有硬解析，只要cpu没有出现性能问题，也是可以容忍的，比较硬解析也有它的好处的
6. Redo NoWait 说明在产生日志的时候，没有产生等待，期望值是100%
7. Soft Parse 说明软解析的比例，期望值是100%，有一点要说明的是，不要单方面的追求软解析的高比例，而去绑定变量，要看性能的瓶颈在哪里
8. Latch Hit 说明latch的命中率，期望值是100%，latch类似锁，是一种内存锁，但只会产生等待，不会产生阻塞，和lock还是有区别的，latch是在并发的情况下产生的
9. Non-Parse CPU 说明非解析cpu的比例，越高越好，用100减去这个比例，可以看出解析sql所花费的cpu，100-99.30=0.7，说明花费在解析sql上的cpu很少

* 结合Time Model Statistics

可以看出，在整个sql执行时间（sql execute elapsed time）时间为5552019秒中，解析时间（parse time elapsed）用了36秒，硬解析时间（hard parse elapsed time）用了34秒虽然硬解析时间占了整个解析时间的绝大部分，但解析时间是花的很少的，所以可以判断出，sql的解析没有成为性能的瓶 颈，进一步推测，sql在获取数据的过程中遇到了瓶 颈

* 继续看Top 5 Timed Events，从这里可以看出等待时间在前五位的是什么事件，基本上就可以判断出性能瓶颈在什么地方

1. buffer busy waits 说明在获取数据的过程中，频繁的产生等待事件，很有可能产生了热点块，也就是说，很多会话都去读取同样的数据块，这一事件等待了5627394次，总共等待了5322924秒，平均等待时间为946毫秒，而且频率也是最高的，有95.9%，等待类别是并发
这里有一个概念：oracle操作的最小单位是块，当一个会话要修改这个块中的一条记录，会读取整个块，如果另一个会话要修改的数据也正好在这个块中，虽然这俩个
2. 会话修改的记录不一样，也会产生等待direct path write temp和direct path read temp 说明用到了临时表空间，那我们再看一下Tablespace IO Stats



各项指标都是非常高的，再根据上面的In-memory Sort是100%，没有产生磁盘排序，也就在排序的时候没有用到临时表空间，进一步推测，多个session，每个session执行的sql语句中多表关联，产生了很多中间数据，pga内存中放不下，
用到了临时表空间，也有可能是用到了lob字段，在用lob字段的时候，也会用到临时表

* 继续看SQL Statistics
根据buffer busy waits等待次数，时间，频率都是最高的，我们重点看逻辑读，物理读，和执行时间最长的sql，把排在前几位的拿出来优化
优化的原则为降低物理读，逻辑读，sql语句中的子操作执行次数尽量少，在看oracle估计出来的执行计划是看不出子操作的执行次数的，要看运行时的执行计划

* 有兴趣的话还可以看一下Segment Statistics
列出了用到的索引和表的使用情况，从这里也能看出索引和表的使用频率

* 也可以看一下Load Profile
里面列出了每秒，每个事务所产生的日志，逻辑读和物理读等指标