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*fromdba_hist_wr_control;DBIDSNAP_INTERVALRETENTIONTOPNSQL-----------------------------------------------------------262389084+0000001:00:00.0+0000700:00:00.0DEFAULT

正常的每小时产生一个SNAPSHOT，保留7天。但一些基表如WRH$_ACTIVE_SESSION_HISTORY因为某些原因没有根据sys.wrm$_wr_control的设定进行清理。SNAPSHOT快照的保留就会超过7天，这时会导致SYSAUX被撑爆，以及收集AWR报告很慢的情况。具体解决办法2个：

1）alter session set “_swrf_test_action”=72;

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

execdbms_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 ID387914.1)

3、系统资源I/O、CPU使用率过高

当系统负载很高时，许多用户进程都在争用资源，AWR报告的收集需要消耗系统主机的性能，当awr报告的收集时间超过15分钟，若这个时候数据库处于相当繁忙的状态，数据库为了保证业务的正常运行，就自动把AWR的功能关闭，减少系统的开销，这是11g功能的增强。这种情况基本如下：

alert.log中会出现如下告警信息：

SuspendingMMONslaveactionxxxfor82800seconds

或者mmontrc中出现如下的告警信息：

UnabletoscheduleaMMONslaveat:AutoFlushMain1Slaveactionhasbeentemporarilysuspended-Slaveactionhadpriorpolicyviolations.Unknownreturncode:101

--可根据https://community.oracle.com/thread/2153562参考：Ifthesystemissoover-loadedthatittakesover15minutestogatherstatisticsorotherMMONtasks,thiserrorisexpected.Itisafunctionalityenhancementin11g,asitpreventsMMONfromlockingresourcesthoseotherprocessesmightbewaitingfor.In10g,mmonslavesareallowedtorunindefinitely.

从日志看，存在大量的Slaveactionhasbeentemporarilysuspended，这是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进程是否存oracle326741021:22?00:00:01ora_mmon_<sid>oracle326761021:22?00:00:01ora_mmnl_<sid>

这两个进程是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-encounterederror:(ORA-12751:cputimeorruntimepolicyviolation)***SQLSTR:total-len=295,dump-len=240,STR={insertintoWRH$_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.valuefromv$active_servicesasvc,v$service_st}DDErulesonlyexecutionfor:ORA-12751


查看该SQL为何执行缓慢，发现v$service_stats视图数量很大。该视图记录的是最小的性能统计数据集，其中有个自动service_name来着v$services，它显示关于服务的信息。expdp每次备份开始，都会新增一个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)