問題描述：
一個壓力測試環境，需要模擬大量數據，于是寫了個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是否知其所以然否？

總結

以上是生活随笔為你收集整理的归档日志满导致ORA-13516错误，AWR报表不能自动收集的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。