一个执行计划异常变更的案例 - 外传之AWR

之前的几篇文章:
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》
《一个执行计划异常变更的案例 - 外传之rolling invalidation》
《一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)》
《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》

作为一款成熟的商业软件,Oracle提供了非常丰富的问题诊断方法和工具,AWR就是其中之一。

AWR(Automatic Workload Repository),从Oracle 10g开始引入,之前同质的工具叫Statspack(Oracle 8.1.6引入),两个报告都可以提供一段时间内数据库系统负载、Top等待事件、Top SQL等相关统计信息,辅助故障的排查和处理,AWR会比Statspack提供的信息更加丰富,因此会更加常用一些。

eygle曾经有一篇系列文章介绍了Statspack:
《Statspack专题》(http://www.eygle.com/archives/2004/11/statspack_list.html)
还有一些大师对如何分析AWR报告有比较详细的讲解,例如,
韩锋老师的《循序渐进解读Oracle AWR性能分析报告》(http://dbaplus.cn/news-10-734-1.html)
Maclean Liu的《Oracle调优鹰眼,深入理解AWR性能报告》(http://www.askmaclean.com/archives/awr-hawk-eyes-training.html)
都是不错的学习教材。

下面摘录一些当时看尼大师(尼米克)著作AWR这一章节做的笔记,精辟地说明了AWR涉及的一些知识,虽然针对的是10g,但大部分内容11g还是适用。
1、AWR全称是Automatic Workload Repository,内容基于AWR资料库中存储的数据,前提是已经购买了相应许可。
2、AWR默认60分钟采集一次统计数据,保存一周,然后删除。统计数据保存在数据库中。
3、为了正确收集统计数据,STATISTICS_LEVEL设置为TYPICAL(默认)或ALL。
4、AWR由许多表组成,这些表属于SYS模式,通常保存在SYSAUX表空间。所有AWR表名都以标识符“WR”开始:元数据(WRM)、历史/可变数据(WRH、WRR和WRI)和和顾问(advisor)功能相关的AWR表(WRI$)。可以对AWR仓库进行查询的DBA视图,以DBA_HIST开头。
5、可以使用DBMS_WORKLOAD_REPOSITORY程序包修改快照收集间隔时间。
exec dbms_workload_repository.modify_snapshot_settings -
(retention=>20160, interval=>15);
使用dbms_workload_repository包的modify_snapshot_settings过程修改快照收集参数,即修改15分钟收集一次,保留时间20160分钟(14天)。
将间隔时间设置为0,则表示停止所有AWR统计数据的收集。
6、查看AWR当前保留时间和时间间隔设置:
select * from dba_hist_wr_control;

这里的列TOPNSQL,在《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》这篇文章中曾介绍过他的含义以及修改方法,可以参考。
7、创建或删除快照:
exec dbms_workload_repository.create_snapshot;
exec dbms_workload_repository.drop_snapshot_range(low_snap_id=>1107, high_snap_id=>1108);
8、查看所有快照:
select snap_id, begin_interval_time, end_interval_time from dba_hist_snapshot order by 1;
9、10g使用名为GATHER_STATS_JOB的调度作业收集AWR统计信息。创建Oracle数据库时,就会自动创建并激活这项作业。查看作业,可参考视图:
select a.job_name, a.enabled, c.window_name, c.repeat_interval
from dba_scheduler_jobs a, dba_scheduler_wingroup_members b, dba_scheduler_windows c
where job_name=’GATHER_STATS_JOB’
and a.schedule_name=b.window_group_name
and b.window_name=c.window_name;
回显:
GATHER_STATS_JOB TRUE WEEKEND_WINDOW freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0
GATHER_STATS_JOB TRUE WEEKNIGHT_WINDOW freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0
表示有两个窗口执行统计信息收集的作业。WEEKEND_WINDOW是每周六00:00执行。WEEKNIGHT_WINDOW是每周一至周五22:00执行。
10g的统计信息自动收集有一些缺陷,例如只有两个维护窗口,调整不灵活,且并没有对这两个维护窗口施加资源限制,可能会影响正常的业务。
10、11g则优化了统计信息的自动收集策略,引入了七个维护窗口,可以看出每个维护窗口会有资源限制,周一至周五是22:00开始,最长执行4小时,周六日是06:00开始,最长执行20小时,

11、禁用和启动作业的方法:
exec dbms_scheduler.disable(‘GATHER_STATS_JOB’);
exec dbms_scheduler.enable(‘GATHER_STATS_JOB’);
12、可以使用如下脚本运行AWR快照:
$ORACLE_HOME/rdbms/admin/awrrpt.sql或awrrpti.sql。
13、AWR内创建基线,定义为某个范围内的快照,可以用来与其它快照进行比较。
创建基线:
exec dbms_workload_repository.create_baseline (start_snap_id=>1109, end_snap_id=>1111, baseline_name=>’EOM Baseline’);
查看基线:
select baseline_id, baseline_name, start_snap_id, end_snap_id from dba_hist_baseline;
删除基线:
exec dbms_workload_repository.drop_baseline(baseline_name=>’EOM Baseline’, Cascade=>FALSE);
参数Cascade如果设置为true,就会删除所有相关的快照,此处会删除1109和1111这两个相关的快照。否则AWR自动进程会自动清除这些快照。

实验:
1.执行$ORACLE_HOME/rdbms/admin/awrrpt.sql,

选择输出文件类型,可以试HTML或文本文件,HTML展示更清晰,而且有超链接可用。

2.若是单实例此处无需选择,若是RAC,则需要选择创建的具体实例(也有针对所有RAC节点的统一AWR报告生成脚本),还需要选择创建的快照日期,默认是当天,

3.针对(2)日期的所有快照列表,需要选择开始和结束的快照ID,

4.选择输出文件名称,默认是awrrpt_实例序号开始快照ID结束快照ID.html,

5.输出生成的html文件源码,

此时这份AWR报告就创建在当前目录下。

6.可以使用浏览器打开AWR,

7.接下来就可以查看AWR报告内容了,

AWR报告中会介绍操作系统的配置信息、系统负载情况、TOP等待事件、CPU/IO/MEMORY的分析数据、TOP SQL(按照执行事件、CPU消耗时间、逻辑读、物理读、执行次数等)、参数设置建议等。

总结:
AWR报告的创建其实很简单,只要找出需要分析的时间段,且在快照保存的周期之内,就可以采集出指定时间段的系统负载、TOP等待事件、TOP SQL等指标。难点在于对AWR报告的分析,而且需要综合分析各种指标,才能得到一个问题的真正原因,只是片面地看一个指标,很可能会被假象迷惑,我现在仍在学习的路上,欢迎大家有问题一起探讨。

时间: 2024-09-23 23:12:54

一个执行计划异常变更的案例 - 外传之AWR的相关文章

一个执行计划异常变更的案例 - 外传之SQL Profile(上)

之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> <一个执行计划异常变更的案例 - 外传之rolling invalidation> <一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)> <一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法> <一个执

一个执行计划异常变更的案例 - 外传之直方图

今天单位值班,有一些时间可以继续完成这篇连载文章.首先祝所有朋友新年快乐!感谢你们在这一年当中对我文章的关注和指点,来年我们共同继续努力! 之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> <一个执行计划异常变更的案例 - 外传之rolling invalidation> <一个执行计划异常变更的案例 - 外传之聚簇因子

一个执行计划异常变更的案例 - 外传之SQL AWR

之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> <一个执行计划异常变更的案例 - 外传之rolling invalidation> <一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)> <一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法> <一个执

一个执行计划异常变更的案例 - 外传之ASH

之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> <一个执行计划异常变更的案例 - 外传之rolling invalidation> <一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)> <一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法> <一个执

一个执行计划异常变更的案例 - 外传之SQL Profile(下)

之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> <一个执行计划异常变更的案例 - 外传之rolling invalidation> <一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)> <一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法> <一个执

一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)

之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> <一个执行计划异常变更的案例 - 外传之rolling invalidation> 这个案例中涉及到了聚簇因子,所以本篇文章是这个系列的又一篇外传,写过上面几篇后,感觉现在就像打怪,见着真正的大BOSS之前,要经历各种小怪的骚扰,之所以写着几篇文章,真是因为这个案例涉及了很多知

一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法

之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> <一个执行计划异常变更的案例 - 外传之rolling invalidation> <一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)> 本篇外传主要介绍一些常用的执行计划查看方法. SQL的执行计划实际代表了目标SQL在Orac

一个执行计划异常变更的案例 - 外传之rolling invalidation

刚做完一次网络切换支持,得空写一篇,其实今儿取了巧,这篇文章是之前写过的,碰巧又是这次"执行计划异常变更"案例涉及的一个知识点,所以再次翻出来. 之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> 做性能测试,有一条SQL,使用了绑定变量,查看V$SQLAREA发现version_count是2, 查看V$SQL,发现有

一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法

这篇外传之前有这么几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> 上一篇文章介绍了绑定变量以及11g之前绑定变量窥探的影响,这篇文章会介绍几种查看绑定变量值的方法. 上篇文章我们说了,绑定变量实际是一些占位符,可以让仅查询条件不同的SQL语句可以重用解析树和执行计划,避免硬解析.绑定变量窥探则是第一次执行SQL硬解析时,会窥探使用的绑定变量值,根据该值的分布特征,选择更合适的执行计划,副作用就是如果绑定变量列值分布不均匀