归档日志满导致ORA-13516错误,AWR报表不能自动收集
2012-11-29 00:23
1021 查看
问题描述:
一个压力测试环境,需要模拟大量数据,于是写了个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是否知其所以然否?
一个压力测试环境,需要模拟大量数据,于是写了个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-03113:通信通道的文件结尾 因为 db_recovery_file_dest_size设置小 导致联机日志不能归档 Oracle不能起来
- oracle归档日志满了,导致oracle用户不能登录
- DB或DG出现的ORA-16038解决-日志无法归档(startup时log不能archive)
- 密码文件丢失导致不能登录pl/sql 错误 ora-01031 权限不足
- db_recovery_file_dest_size设置小 导致联机日志不能归档 Oracle不能起来
- ORA-00257 归档日志错误的解决方案
- 11.2.0.3 ASM实例出现ORA-4031错误导致数据库归档失败
- 归档日志满以后引起的错误 Caused by: java.sql.SQLException: ORA-00257:
- Oracle手动删除归档日志厚,出现ORA-19571错误
- 误删除日志文件导致出现 ORA-01034&ORA-27101错误
- DG不能自动mount导致数据库不能正常启动:ORA-01157、ORA-01110、ORA-17503、ORA-15001、ORA-15001
- 11.2.0.3 ASM实例出现ORA-4031错误导致数据库归档失败
- oracle数据库连接时提示ora-00257错误,提示数据库归档日志归档失败
- 磁盘空间不足导致日志不能归档
- 统计信息自动收集时间窗口导致分区表执行计划错误
- ADO在查询视图时自动添加rowid,导致Ora 1445错误
- ORA-00376错误 利用归档日志恢复数据文件
- Oracle归档日志满了导致Oracle连接(ORA-00257)报错处理
- ORA-03113: end-of-file on communication channel ORA-00257: archiver error. Connect 归档日志满导致数据库没有办法启动
- ora-00257数据库日志归档器错误解决方法