歸檔日誌滿導致ORA-13516錯誤，awr報表不能自動收集

問題描述：
一個壓力測試環境，需要模擬大量資料，於是寫了個job在週末跑，結果今天來看結果的時候，發現由於產生大量的歸檔日誌，導致磁碟空間耗盡，job已經停了。看看資料也造的差不多，也沒在意。於是QA開始做壓力測試，但是壓了一段時間去看AWR報表的時候，卻發現最新的報表只到週末為止，沒有新的自動收集的報表產生？？？

[@more@]

這樣的問題是第一次碰到，首先到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是否知其所以然否？