归档日志满导致ORA-13516错误，AWR报表不能自动收集

问题描述：
一个压力测试环境，需要模拟大量数据，于是写了个job在周末跑，结果今天来看结果的时候，发现由于产生大量的归档日志，导致磁盘空间耗尽，job已经停了。看看数据也造的差不多，也没在意。于是QA开始做压力测试，但是压了一段时间去看AWR报表的时候，却发现最新的报表只到周末为止，没有新的自动收集的报表产生？？？

这样的问题是第一次碰到，首先到DBA_HIST_SNAPSHOT查询最新的记录，结果确实没有最新的记录产生。接下来手工的去创建一次信息统计：
SQL> exec dbms_workload_repository.create_snapshot;

begin dbms_workload_repository.create_snapshot; end;

ORA-13516: AWR Operation failed: only a subset of SQL can be issued
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 10
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 33
ORA-06512: at line 1
错误信息说明DBMS_WORKLOAD_REPOSITORY包执行的第十行有错，查看此包的代码准备进行单步跟踪，结果发现此包的代码是加密的。尝试把以前收集的统计信息全部删除，然后再重新创建新的：
SQL> exec dbms_workload_repository.drop_snapshot_range(low_snap_id => 0,high_snap_id => 10000);

begin dbms_workload_repository.drop_snapshot_range(low_snap_id => 0,high_snap_id => 10000); end;

ORA-13516: AWR Operation failed: only a subset of SQL can be issued
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 65
ORA-06512: at line 1
结果出现同样的错误，看来此路不通。google了一把，发现有人碰见过类似的错误（原文链接），不过他是升级到10G出现的问题，按照提供的一点线索，执行：
SQL> SELECT NAM.KSPPINM NAME, VAL.KSPPSTVL, NAM.KSPPDESC DESCRIPTION
2 FROM X$KSPPI NAM, X$KSPPSV VAL
3 WHERE NAM.INDX = VAL.INDX
4 AND NAM.KSPPINM = '_awr_restrict_mode'
5 ORDER BY 1;

NAME KSPPSTVL DESCRIPTION
-------------------- ---------------- -----------------------
_awr_restrict_mode FALSE AWR Restrict Mode

从返回结果没有得到什么帮助信息。后来想到awr是通过什么方式实现定时收集信息的呢？无非是job、schedule或者后台进程，查看了job和schedule后没发现有awr相关的信息，于是注意力转移到后台进程。GOOGLE一把ORA-13516、后台进程两个关键字，得到了awr执行是通过MMON进程来执行的，于是到服务器上执行：
[root@db1 ~]# ps -ef | grep mmon
root 8028 13026 0 17:45 pts/1 00:00:00 grep mmon
可以看到没有mmon进程了，而另外几个机器执行相同的命令都有mmon进程存在，看来是这个进程宕掉了。这时才想起来看alert文件，因为测试环境发生过多次的归档日志满的情况，都是直接删除些文件，腾出点空间，然后就ok了，也没注意到mmon进程或者其他进程是否宕掉。alert中有如下的记录：
ORA-19502: write error on file "/u02/archive/db/Arc_1_178_629204558.arc", blockno 14337 (blocksize=512)
Sat Aug 11 16:26:05 2007
ARC1: Failed to archive thread 1 sequence 178 (19502)
Sat Aug 11 16:32:23 2007
Shutting down instance: further logons disabled
Sat Aug 11 16:34:14 2007
Stopping background process QMNC
Sat Aug 11 16:34:14 2007
Stopping background process CJQ0
Sat Aug 11 16:34:16 2007
Stopping background process MMNL
Sat Aug 11 16:34:24 2007
Stopping background process MMON
Sat Aug 11 16:34:25 2007
Shutting down instance (normal)
License high water mark = 625
Sat Aug 11 16:34:25 2007
Stopping Job queue slave processes
Sat Aug 11 16:34:25 2007
Job queue slave processes stopped
Sat Aug 11 16:53:16 2007
MMNL absent for 1202 secs; Foregrounds taking over

日志中明确记录了QMNC、CJQ0、MMNL、MMON四个进程都宕了，查询资料，这四个进程分别是负责以下工作：
1、QMNC进程对于AQ表来说就相当于CJQ0进程之于作业表，QMNC进程会监视高级队列，并警告从队列中删除等待消息的“出队进程”（dequeuer）
2、CJQ0进程是作业队列协调器（job queue coordinator）
3、MMNL是可管理性监视器灯（manageability monitor light）
4、MMON是可管理性监视器（manageability monitor）

MMON、MMNL和Mnnn这些进程用于填充自动工作负载存储库（Automatic Workload Repository，AWR），这是Oracle 10g中新增的一个特性。MMNL进程会根据调度从SGA将统计结果刷新输出至数据库表。MMON进程用于“自动检测”数据库性能问题，并实现新增的自调整特性。Mnnn进程类似于作业队列的Jnnn或Qnnn进程；MMON进程会请求这些从属进程代表它完成工作。Mnnn进程本质上是临时性的，它们将根据需要来来去去。
由此可见，MMON和MMNL进程宕掉是awr不能自动收集的根本原因，但是这个咚咚为什么会宕，宕了之后为什么不自动起来？不得而知！重新google了半天，没有答案，由于是测试库，按照前面那个老兄的解决办法，重新启动了database后，一切恢复正常。

总结：任何问题都有原因的，可是我知其然，不知道oracle是否知其所以然否？