AWR & Alert System

1. AWR & Alter System

2. Overview
• AWR, 是Automatic Workload Repository的缩
写, 它是oracle数据库自带的系统监控和诊断工
具, 熟练使用该工具对DBA的日常数据库管理
会有极大的帮助. 本章包含了下面的内容:
– 使用和管理AWR
– 使用AWR顾问框架(Advisory Framework)
– 管理数据库告警日志和阀值

3. AWR
- Overview
• Oracle数据库在运行时会收集大量与性能和系统活动相关的
统计信息, 这些信息被写入到AWR相关的表中, 这些表被存
储在SYSAUX表空间中. 使用实例参数STATISTICS_LEVEL控制
统计数据的收集, 该参数的取值有:
– BASIC 关闭统计数据的收集
– TYPICAL 收集基本的统计数据, 通常而言此设置可以满足
所有的要求
– ALL 收集非常详尽的统计数据, 这会对系统性能造成
一定的影响
• 统计数据被收集在SGA内存中, 按照一定的时间间隔(默认为
1个小时)被写入到AWR表中, 一次写入被称为一个AWR快照
(snapshot), 这个过程是由MMON进程执行的. 快照默认的保
存时间是8天.
• AWR表创建在SYSMAN模式下面, oracle不支持对这些表的直
接访问, 可以通过database control以sysman登录访问AWR的
信息.

4. AWR
- Manage
• 按照AWR的默认配置: 每小时生成一次快照, 快照保留8天, 这样AWR
会大致占用SYSAUX表空间200-300M的空间. 通过database control查
看和管理AWR, 路径: Server > Statistics Management > AWR如下:
Tip: 使用更短的时间间隔做AWR快照可以更为准确地监控系统状况,
但这会导致占用更多的空间. 需要有计划地监控SYSAUX表空间的使
用和增长情况, 可以通过v$sysaux_occupants视图可以查看AWR占用
的空间大小.
Tip: 使用dba_hist_snapshot查看历史AWR快照.

5. Statistics, Metrics & Baselines
• 在oracle数据库性能诊断领域, 有三个重要的概念分别是:
– Statistic
统计数据, 包含在AWR快照中, 它是关于数据库性能和活动情况的
基础数据.
– Metric
度量, 度量是由统计数据得到的. 比如: 磁盘读写次数, 这是一个
statistic, 可以将它转化为每秒磁盘读写次数, 或者说每个事务/SQL
语句的磁盘读写次数, 这就是metric.
– Baseline
基线指的是stat和metric的集合, 它用于与其他的基线进行比较, 以
衡量系统性能的变化.
• MMON进程在保存AWR快照时, 会自动从stat中计算出大量
的预定义metric, baseline则需要DBA手动地创建, 比如在每个
月底创建baseline. 可以通过database control设置一定的时间
间隔自动创建baseline.

6. DBMS_WORKLOAD_REPOSITORY
• 这是与AWR相关的PLSQL包, 可用于:
– 调整AWR快照和保存时间 modify_snapshot_settings, 示例:
execute DBMS_WORKLOAD_REPOSITORY.
modify_snapshot_settings’(retention=>43200, interval=>30);
– 创建临时(ad hoc)AWR快照 create_snapshot
– 创建和管理baseline create_baseline, 示例:
execute DBMS_WORKLOAD_REPOSITORY. create_baseline(start_snap_id => 487,
end_snap_id => 488, baseline_name => 'FridayPM');
– 比较任意两个快照, 并生成报表.
• 练习: 监控AWR
– 查看AWR在sysaux表空间占用的空间
select occupant_desc,space_usage_kbytes from v$sysaux_occupants
where occupant_name='SM/AWR';
– 创建一个AWR快照
execute dbms_workload_repository.create_snapshot;
– 查询快照数量, 以及所有这些快照覆盖的时间
select min(begin_interval_time), max(begin_interval_time),
count(snap_id) from dba_hist_snapshot;

7. Database Advisory Framework
• Oracle数据库自带了很多的顾问程序(advisors), 这些程序基于AWR收集的数
据库性能和活动统计信息发现一些存在的问题, 并指出解决的方法. 最常用
的advisor是ADDM(Automatic Database Diagnostics Monitor), 它会在每次作
AWR快照时生成相关的报表, 该报表是DBA进行系统性能分析和问题排查
的出发点, 它会给出以下意见:
– 添加硬件资源(比如: CPU, 内存 etc)
– 更改数据库配置(比如: 修改实例参数)
– 修改对象(比如: 表/索引分区)
– 应用层调优(比如: 使用绑定变量)
– 建议使用其他的顾问程序(比如: 使用Memory Advisor)
• 下面是oracle提供的顾问程序列表:
– ADDM
– Memory Advisor
– SQL Access, Tuning, and Repair Advisor
– Automatic UNDO Advisor
– MTTR Advisor
– Data Recovery Advisor
– Segment Advisor

8. ADDM
• 在生成AWR快照(无论是系统自动生成还是手工)时, MMON进
程会调用ADDM, ADDM比较当前AWR快照和之前的AWR快照并
生成相应的报表. 可以基于指定的任意两个快照手工调用
ADDM, ADDM报表默认被保存30天.
• 通过Database Control访问ADDM报表: Related Links -> Advisor
Central, 查看ADDM报表:

9. Other Advisors
• Memory Advisor
内存顾问程序, 按照SGA的结构可以分为SGA顾问、共享池顾问、
Java池顾问、流池顾问、数据缓冲区顾问、PGA顾问等; 但不包含大
池顾问.
• SQL Advisor
有三个sql顾问程序: SQL Access顾问(SAA)、SQL Tuning顾问(STA)、
SQL Repair顾问(SRA). SAA会根据SQL的访问情况提出包含创建和删
除索引、使用物化视图和分区在内的建议; STA会针对单个SQL语句
提出相应的调优建议: 比如更新统计信息、重写SQL语句; 针对ORA-
600错误, SRA可以迫使SQL语句选择某个执行计划从而避免该错误.
• Automatic UNDO Advisor
AUA通过观察UNDO的生成速率和SQL语句执行的时间, 计算UNDO表
空间最小要求的大小, 从而避免出现ORA-01555快照过旧错误.
Tip: 根据Oracle读一致性, 比如某SQL语句在时间点A执行, 在执行过
程中有可能需要应用UNDO以读取某个段在时间点A的数据, 如果执
行的时间过长导致UNDO被覆盖, 就会抛出ORA-01555错误.

10. Other Advisors
• MTTR Advisor
MTTR顾问描述实例恢复需要的时间.
• Data Recovery Advisor(DRA)
DRA顾问提出与数据库恢复相关的建议, 比如数据
文件丢失可以在启动时使用DRA生成相应的恢复
脚本.
• Segment Advisor
对段的数据进行删除和更新操作时, 段不会进行
自动的shrink操作, 这会导致段里面有大量的碎片
空间. 段顾问会根据段的当前状态和历史使用情
况, 建议进行相关的重组织操作(segment
reorganization), 以消除这些碎片空间.

11. Automatic Maintenance Jobs
• 如果是使用DBCA创建的数据库, 那么下面的三个
系统维护任务会被自动调度执行, 它们被配置在
称为AutoTask的系统中:
– 收集优化器统计数据
– 执行Segment Advisor
– 执行SQL Advisor
这些任务在系统调度的维护窗口(maintenance window)
中运行, 默认设置下该窗口周一到周五于22:00打开持续4
小时, 周末于6:00打开持续20小时.
Tip: AutoTask任务的运行依赖于STATISTICS_LEVEL
参数的配置, 该参数值必须设置为Typical或者All.

12. Alert System
- Overview
• Oracle告警系统用于对系统的整体状态进行监控, 在超过某
个metric的阀值设置时发出警告(通过邮件或者其它的方式).
最常见的一个应用是监控数据库表空间的空间使用情况:默
认情况下, 系统会在表空间使用达到85%和97%分别发出警
告(warning)和严重警告(critical alert).
• 告警系统的运行机制
在设置系统阀值(保存在AWR中)之后, MMON进程会定时使
用系统实际情况与阀值进行比较, 如果超过了该阀值则发出
一个警告并放入(enqueue)告警队列中(alert queue), 默认情
况下EM会从将告警消息并显示在主页. 可以配置EM执行其
它的动作比如发送SMS或者邮件. 通过dba_outstanding_alerts
查看未处理的告警.
• 告警的类型
告警可以被分为两种类型: stateful和stateless. 前者是基于条
件设置(阀值)触发的, 可以被解决, 比如表空间使用超过阀值;
后者则是在发生某些事件时触发的, 比如数据库发生死锁.

13. Alert System
- Threshold
• 可以为超过200个度量(metric)设置阀值, 这些metric保存在v$metricname视图中, 可
以查看度量的名称、单位以及ID. 使用类似如下PLSQL设置阀值:
execute dbms_server_alert.set_threshold(
metrics_id=>dbms_server_alert.redo_generated_sec,
warning_operator=>dbms_server_alert.operator_ge,
warning_value=>'1000000',
critical_operator=>dbms_server_alert.operator_ge,
critical_value=>'2000000',
observation_period=>1,
consecutive_occurrences=>5,
instance_name=>'ORCL11G',
object_type=>dbms_server_alert.object_type_system,
object_name=>null);
解释如下:
1, dbms_server_alert.set_threshold用于设置或者更新阀值;
2, 设置的度量是每秒钟生成redo的数量, 使用bytes/second为单位;
3456, 分别设置发出warning/critical alert的条件, 大于1m/2m;
78, 设置监控的时间间隔(minute)和发出警告时连续超过阀值的次数;
9, 设置instance名称, 对于RAC;
总体来说, 当系统在连续5分钟之内平均每秒钟中生成的redo超过1m/2m时, 分别发
出普通警告和严重警告.

14. Alert System
- Notification
• stateful的告警信息会写入到dba_outstanding_alerts视
图中, 并显示在EM的首页. 当相应的问题被解决时, 告
警从该视图转移到dba_alert_history视图中. 可以通过
下面的步骤配置额外的处理方式:
– 配置通知方法, 比如邮件、SMS
在EM中点击Setup>Notification Methods设置;
– 配置规则
通常需要为规则设置一个或者多个metric, 规则对这些metric
进行监控. 在EM中点击Preferences > Rules设置.
– 订阅上面配置的规则
可以指定某些系统用户比如SYS、SYSTEM、SYSMAN等订阅这
些规则, 它们将收到通知.在EM中点击setup>administrators设置.

15. END