AWR

(

Automatic Workload Repository

)作为对数据库性能诊断的工具，采集与性能相关的统计数据，根据这些统计数据中的性能指标，以跟踪潜在的问题。若因某些情况导致相关数据无法收集，就会对数据库性能诊断大打折扣。

以下列举

AWR

收集缓慢、挂起或缺失常见的几种情况：

STATISTICS_LEVEL

参数不为

ALL

或

TYPICAL

SYSAUX

表空间不足

系统资源

I/O

、

CPU

使用率过高

MMON/MMNL

进程异常

相关

FIXED TABLE

统计信息不准确

1、STATISTICS_LEVEL

参数不为

ALL

或

TYPICAL

初始化参数

STATISTICS_LEVEL

，

AWR

的采集信息受到参数

STATISTICS_LEVEL

的影响。这个参数有三个值：

BASIC

：

AWR

统计信息的关闭，只收集少量的数据库统计信息。

TYPICAL

：默认值，只有部分的统计收集，都是需要监控

oracle

数据库的典型行为。

ALL

：所有可能的统计都被捕捉，并且有操作系统的一些信息，这个级别的捕捉用的较少，比如要更多的

sql

诊断信息。

一般不会随便修改该参数，都使用默认值

TYPICAL

，所以这种情况下导致

AWR

无法收集统计数据的很少的。

2、SYSAUX

表空间不足

AWR

采集的统计数据都以

WRM$_*

和

WRH$_*

的格式命名的表存储在

SYSAUX

表空间上(

M

代表元数据

(metadata)

，而

H

代表历史数据

(historical)

)。可通过

@?/rdbms/admin/awrinfo.sql

或

x$kewrtb

查询相关的表信息。虽然

因

SYSAUX

表空间不足导致

AWR

无法生成是个低级问题

，但是有一种情况需要注意，因为

BUG

等导致

ASH/AWR

的基表数据无法清理。如：

SQL> select * from dba_hist_wr_control;      DBID SNAP_INTERVAL        RETENTION            TOPNSQL

---------- -------------------- -------------------- ---------262389084 +00000 01:00:00.0    +00007 00:00:00.0    DEFAULT

正常的每小时产生一个

SNAPSHOT

，保留

7

天。但一些基表如

WRH$_ACTIVE_SESSION_HISTORY

因为某些原因没有根据

sys.wrm$_wr_control

的设定进行清理。

SNAPSHOT

快照的保留就会超过

7

天，这时会导致

SYSAUX

被撑爆，以及收集

AWR

报告很慢的情况。具体解决办法

2

个：

1)alter session set “_swrf_test_action”=72;

2) 手工删除过期无用的快照：

exec dbms_workload_repository.drop_snapshot_range(low_snap_id => xxx, high_snap_id => xxxx, dbid => 262389084);

MOS

文档：

WRH$_ACTIVE_SESSION_HISTORY Does Not Get Purged Based Upon the Retention Policy (Doc ID

)

3、

系统资源

I/O

、

CPU

使用率过高

当系统负载很高时，许多用户进程都在争用资源，

AWR

报告的收集需要消耗系统主机的性能，当

awr

报告的收集时间超过

15

分钟，若这个时候数据库处于相当繁忙的状态，

数据库为了保证业务的正常运行，就自动把

AWR

功能的增强

。这种情况基本如下：

alert.log

中会出现如下告警信息：

Suspending MMON slave action xxx for 82800 seconds

或者

mmon trc

中出现如下的告警信息：

Unable to schedule a MMON slave at: Auto Flush Main 1

Slave action has been temporarily suspended    - Slave action had prior policy violations.

Unknown return code: 101

--可根据参考：If the system is so over-loaded that it takes over 15 minutes to gather statistics or other MMON tasks, this error is expected.It is a functionality enhancement in 11g, as it prevents MMON from locking

resources those other processes might be waiting for. In 10g , mmon slaves are allowed to run indefinitely.

从日志看，存在大量的

，

这是

11g

功能的增强，当系统处于

overload

状态时，

MMON

进程收集统计信息超过

15

分钟，则会终止该任务，

10g

会无限延期。所以系统资源不足也会导致

AWR

统计信息无法正常收集。

为什么是

15

分钟？请参考

MOS

文档：

Troubleshooting ORA-12751 "cpu time or run time policy violation" Errors (

文档

ID 761298.1)

Troubleshooting: Missing Automatic Workload Repository (AWR) Snapshots and Other Collection Issues (

文档

ID 1301503.1)

4、MMON/MMNL

进程异常

Memory Monitor(MMON)

：

MMON

主要用于

AWR

，

ADDM

，

MMON

会从

SGA

将统计结果写到系统表中

The Memory Monitor Light (MMNL)

：

mmon

进程主要是内存中

sql

信息，

ash

信息的收集工作，如果这些信息需要写入到磁盘(即一些数据字典表)中，那么就需要

MMNL

进程负责写入

MMON

、

MMNL

和

Mnnn

这些进程用于填充自动工作负载存储库(

Automatic WorkloadRepository

，

AWR

)，这是

Oracle 10g

中新增的一个特性。

MMNL

进程会根据调度从

SGA

将统计结果刷新输出至数据库表。

MMON

进程用于“自动检测”数据库性能问题，并实现新增的自调整特性。

Mnnn

进程类似于作业队列的

Jnnn

或

Qnnn

进程；

MMON

进程会请求这些从属进程代表它完成工作。

由此可见，

MMON

和

MMNL

进程异常是

AWR

不能自动收集的根本原因。

遇到

AWR

无法收集的情况可以根据文档(

ID 1301503.1

)进行排查，检查

mmon

和

mmnl

进程是否正常。

ps -ef|egrep "mmon|mmnl"  #查看mmon和mmnl进程是否存oracle    32674      1  0 21:22 ?        00:00:01 ora_mmon_oracle    32676      1  0 21:22 ?        00:00:01 ora_mmnl_

这两个进程是

oracle

的非核心进程，可以

kill

掉，它们会自动启动进程，并且自动维护。若这两个进程没有问题，可以手动生成

AWR

看是否有效：

exec  dbms_workload_repository.create_snapshot();

然后再进一步诊断问题。

因为这两个进程都非核心进程，所以很多文档都是说可

kill

，重新唤起这个进程，让

AWR

可继续生成。在

11.2.0.4

中可能会存在起不来的情况，原因根据

MOS

文档：

AWR Snapshots Are Not Being Created Because MMON Is Not Being Respawned (

文档

ID 2023652.1)

可知：

5、FIXED TABLE

统计信息不准确

查看

mmon

进程的

trace

文件，出现以下报错：

** KEWROCISTMTEXEC - encountered error: (ORA-12751: cpu time or

run time policy violation)

*** SQLSTR: total-len=295, dump-len=240,

STR={insert into WRH$_SERVICE_STAT   (snap_id, dbid,

instance_number,    service_name_hash, stat_id, value) select

:snap_id, :dbid, :instance_number,   stat.service_name_hash,

stat.stat_id, stat.value from  v$active_services asvc, v$service_st}

DDE rules only execution for: ORA-12751

查看该

SQL

为何执行缓慢，发现

v$service_stats

视图数量很大。该视图记录的是最小的性能统计数据集，其中有个自动

service_name

来着

v$services

，它显示关于服务的信息。e

xpdp

每次备份开始，都会新增一个

service name

，备份结束后会去掉该

service name

，该动作会记录在

alert log

中，这个动作就会导致

v$service_stats

视图出现很多

unknown

的记录。

错误的执行计划：

每次逻辑导出时，会在

v$service_stats

视图中增加

service_name=unknow

的记录，导致

v$service_stats

视图中累积存储了大量

unknow service name

的记录，

AWR

快照生成过程中在执行上述

SQL

时，由于

fixed table

统计信息不准确或者尚无统计信息，

oracle

选择了效率较低的执行计划，

SQL

的执行消耗大量时间，导致

oracle

维护任务

cpu time policy violation

，

AWR

快照生成中断。

解决办法是：手动收集

fixed table

的统计信息(在

12 c

之前，固定的统计数据没有自动收集，它是对所有

X$

基表统计信息的收集，这个收集是要相对比较长时间的，同时评估好收集之后对其它

SQL

语句执行的影响。如

V$SESSION

、

V$PROCESS

、

V$LOCK

等常用视图相关

SQL

语句的执行计划影响)

select table_name,num_rows,last_analyzed from dba_tab_statistics where last_analyzed is not null order by last_analyzed desc;

exec dbms_stats.gather_fixed_objects_stats(no_invalidate => false);

fixed table

的统计信息

请参考文档：Fixed Objects Statistics (GATHER_FIXED_OBJECTS_STATS) Considerations (文档 ID 798257.1)