频繁产生归档日志处理报告

频繁产生归档日志处理报告

2017年10月27日，客户数据库突然间频繁产生大量归档日志，导致数据库hang住，影响现场生产！由于oracle归档日志一般由dml语句产生，所以增加太快应该是dml太频繁。

首先查询以下每小时连接日志切换频率的情况：

select to_char(first_time,'yyyy-mm-ddhh24') first_time,count(*)

from v$log_history

WHERE TO_CHAR(FIRST_TIME,'yyyymmdd')

group by to_char(first_time,'yyyy-mm-ddhh24') order by FIRST_TIME desc；

可以看到数据库每个小时切换的联机日志的次数达650多次，每个连接日志大小是50M，发生切换时会将联机日志写入归档日志，所以归档日志增加很快。一小时产生的归档日志高达30G多。

首先通过AWR报告可以看到数据库的主要负载是产生大量的redo日志：

关键是要找到相应的sql语句，来判断问题发生的情况。所以我们使用logminer工具来分析相应的归档日志，来找到相应的sql语句：

查看磁盘上的归档日志文件的路径和名称：

路径查看语句：show parameter db_recovery！

在相应的目录下找到归档日志：

1，使用脚本创建相关的包

@$ORACLE_HOME/rdbms/admin/dbmslm.sql

@$ORACLE_HOME/rdbms/admin/dbmslmd.sql;

第一个脚本用来创建DBMS_LOGMNR包，该包用来分析日志文件。

第二个脚本用来创建DBMS_LOGMNR_D包，该包用来创建数据字典文件。

2.指定要分析的日志文件

exec sys.dbms_logmnr.add_logfile(logfilename=> '+recoverydata/orcl/adchivelog/2017_10_27/thread_2_seq_148046.384.958475205',options=> dbms_logmnr.new);

3.使用本地的在线数据字典分析归档日志

exec sys.dbms_logmnr.start_logmnr(options=> sys.dbms_logmnr.dict_from_online_catalog);

4,查询分析出来的归档日志内容，例如统计最大修改量的Schema

select seg_owner,count(*) fromv$logmnr_contents group by seg_owner;

select count(1),substr(sql_redo,1,30) fromv$logmnr_contents group by substr(sql_redo,30) order by count(1) desc ;

通过上图可以看到数据库中大量的回滚操作，回滚一般是由于数据库DML语句失败所致，所以再去查看trace日志，发现数据库存在大量的报错信息！如下图所示：

ORA-1654: unable to extend indexMES.PK_BBM_TRACE_INFO by 128 in tablespace MESDB_BASE_DATA01

ORA-1654: unable to extend indexMES.PK_BBM_TRACE_INFO by 1024 in tablespace MESDB_BASE_DATA01

ORA-1654: unable to extend indexMES.PK_BBM_TRACE_INFO by 128 in tablespace MESDB_BASE_DATA01

ORA-1654: unable to extend indexMES.PK_BBM_TRACE_INFO by 1024 in tablespace MESDB_BASE_DATA01

ORA-1654: unable to extend indexMES.PK_BBM_TRACE_INFO by 128 in tablespace MESDB_BASE_DATA01

ORA-1654: unable to extend indexMES.PK_BBM_TRACE_INFO by 1024 in tablespace MESDB_BASE_DATA01

ORA-1654: unable to extend indexMES.PK_BBM_TRACE_INFO by 128 in tablespace MESDB_BASE_DATA01

ORA-1654: unable to extend indexMES.PK_BBM_TRACE_INFO by 1024 in tablespace MESDB_BASE_DATA01

报错已经很清楚的说明，是由于在表空间中无法扩大索引所致！查询相应的表空间，发现表空间只有2G大小，增加表空间到30G，并设置表空间自动增长，最大无限大！

更改完后再次查询联机日志切换频率如下所示：

此时再查询归档日志的增加大小发现已经不增加了。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!