oracle数据库性能awr,ORACLE数据库性能调优的关键工具AWR PDF 下载

主要内容：

今天，我想和大家一起学习一些AWR调优技巧，从而确定如何从一堆历史性能数据中找到调优的关键点。

首先，我们需要了解AWR的数据的组成部分，AWR主要有以下两部分组成：

(1)保存在内存中的系统负载和性能统计数据，主要通过v$视图查询；

(2)mmon进程定期以快照(snapshot)的方式将内存中的AWR数据保存到SYSAUX表空间中，主要通过DBA_*视图访问。

其次，我们需要知道如何生成AWR快照，具体方法如下：

默认情况下，每隔一小时自动产生一个快照，10g保存最近7天的信息，11g保存最近8天的信息，可以通过以下语句查询：

SQL>select SNAP_INTERVAL,RETENTION from dba_hist_wr_control;

SNAP_INTERVAL       RETENTION

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

+00000 01:00:00.0       +00007 00:00:00.0

可以通过以下语句修改时间间隔和保存时间(以分钟为单位)：

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

也可以根据需要随时手动生成快照：

exec dbms_workload_repository.create_snapshot;

AWR报告的生成的命令如下：

以sysdba运行如下命令：

@$ORACLE_HOME/rdbms/admin/awrrpt.sql   单实例的报告

@$ORACLE_HOME/rdbms/admin/awrgrpt.sql   RAC的报告

@$ORACLE_HOME/rdbms/admin/awrrpti.sql   RAC中特定实例的报告

@$ORACLE_HOME/rdbms/admin/awrgrpti.sql   RAC中多个实例的报告

@$ORACLE_HOME/rdbms/admin/awrsqrpt.sql   针对SQL语句的报告

@$ORACLE_HOME/rdbms/admin/awrsqrpi.sql   针对特定实例上某个SQL语句的报告

@$ORACLE_HOME/rdbms/admin/awrddrpt.sql   单实例的时段对比报告

@$ORACLE_HOME/rdbms/admin/awrgdrpt.sql   RAC的时段对比报告

@$ORACLE_HOME/rdbms/admin/awrddrpi.sql   特定实例的时段对比报告

@$ORACLE_HOME/rdbms/admin/awrgdrpi.sql   RAC中多个实例的时段对比报告

最后，在AWR报生成后，我们就可以根据AWR报告来进行分析了，那么具体要怎么做呢？因为AWR报告非常长，不可能从头到尾一字不漏的去看，要有选择的去看重点部分。最好能对照的来读，即和系统正常情况下的AWR报告对比，找差异。AWR报告采用总分的形式，前面是系统的整体情况，后面是各个部分细节，一开始不要陷入细节，先分析系统的整体状况，对于后面的专题分析，要根据关注点的不同，采取跳跃式分析。还要根据具体业务的不同，决定某种现象是否正常。

AWR报告分析可从以下几点入手：

(1)Oacle主机资源开销分析及负载情况

(2)Oracle Top信息分析        Top 10 Foreground Events by Total Wait Time(Top 5 Timed Foreground Events或Top 5 Timed Events，不同版本不同名称)

(3)SQL开销情况            SQL ordered by Elapsed Time

(4)Oracle负载情况          Load Profile

(5)Oracle实例效率分析        Instance Efficiency Percentages (Target 100%)

(6)Oracle共享池分析         Shared Pool Statistics

以Oracle 11g AWR为例：

1.Oracle主机资源开销分析及负载情况：

CPUs：逻辑cpu数

Elapsed：快照监控时间。

DB Time：不包括Oracle后台进程消耗的时间，如果DB Time远远小于Elapsed时间，说明数据库比较空闲。

DB Time= cpu time + wait time(不包含空闲等待) (非后台进程)

如上图，数据库耗时7477.20分钟，共8个逻辑cpu：7477.20÷8=934.65，平均每个cpu耗时934.65分钟

cpu利用率：934.65÷3480.23=0.269，26.9%利用率说明cpu并不空闲；如果超过100%说明出现等待现象。

2.Oracle负载情况：

了解系统整体负载状况，如每秒中的事务数/语句数，每秒/每事务物理读写次数(Physical Reads/Writes)，逻辑读写次数(Logical Reads/Writes)，SQL语句的解析(Parse)，特别是硬解析次数等。

parses：解析次数，软解析加硬解析；

Hard parses：硬解析，万恶之源，会造成多种等待，不要超过每秒20次；

结合Time Model Statistics查看，Hard parses(硬解析数)和hard parse (sharing criteria) elapsed time对应，看一眼Time Model Statistics，即可知该系统是否是解析敏感的

Oracle的硬解析和软解析：

提到软解析(soft prase)和硬解析(hard prase)，就不能不说一下Oracle对SQL的处理过程。当你发出一条SQL语句交付Oracle，在执行和获取结果前，Oracle对此SQL将进行几个步骤的处理过程：

1)语法检查(syntax check)

检查此SQL的拼写是否语法。

2)语义检查(semantic check)

诸如检查SQL语句中的访问对象是否存在及该用户是否具备相应的权限。

3)对SQL语句进行解析(prase)

利用内部算法对SQL进行解析，生成解析树(parse tree)及执行计划(execution plan)。

4)执行SQL，返回结果(execute and return)

其中，软、硬解析就发生在第三个过程里。

Oracle利用内部的hash算法来取得该SQL的hash值，然后在library cache里查找是否存在该hash值；

假设存在，则将此SQL与cache中的进行比较；

假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。

诚然，如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。

创建解析树、生成执行计划对于SQL的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。