失效链接处理 |
ORACLE数据库性能调优的关键工具AWR PDF 下载
本站整理下载:
提取码:fph2
相关截图:
主要内容:
今天,我想和大家一起学习一些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的执行来说是开销昂贵的动作,所以,应当极力避免硬解析,尽量使用软解析。
|