ITPub博客

首页 > 数据库 > Oracle > 归档日志满导致ORA-13516错误,awr报表不能自动收集

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

原创 Oracle 作者:zhang41082 时间:2019-05-25 10:12:06 0 删除 编辑

问题描述:
一个压力测试环境,需要模拟大量数据,于是写了个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是否知其所以然否?

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25016/viewspace-955196/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2002-10-11

  • 博文量
    79
  • 访问量
    60453