oracle 归档日志激增,一次归档日志激增的分析. logmnr

OS:redhat as 4:9207

我们的生产库正常情况下一天产生400-500个日志.每个日志大小20M.

最近发现日志量大量增加.更加奇怪的是白班(07:30--19:30)的日志是正常的.晚班(19:30--07:30)的日志就大量增加了(1小时就能产生200个日志).第一反应就是怀疑有人在晚班做了大量的DML操作.所以就去问开发人员有没有做什么动作.一致都说没有什么动作.也查看了下JOB,没有发现有JOB在晚班跑.

没办法.只能利用LOGMNR分析日志了.

但是问题又来了.发现之前还没有设置utl_file_dir这个参数呢.此参数为静态参数.生产库是没办法停机重启的.所以就想到了将日志移至库(与生产库环境是相同的)进行分析.以下就是在测试环境下的分析过程.

确定初始化参数 UTL_FILE_DIR 的值(默认为空),用下面的语句可以创建，或者用oem   如何重启

SQL> alter system set utl_file_dir="F:\oracle\product\10.1.0\admin\otherdb\log"    SCOPE=SPFILE;

System altered.

1.创建正式库数据字典文件，将它拷贝至测试库.BEGIN

dbms_logmnr_d.build(dictionary_filename => 'dictionary1.ora',dictionary_location => 'F:\oracle\product\10.1.0\admin\otherdb\log');

END;

2.拷贝晚班大量产生的日志(1_267220.dbf--1_267225.dbf)6个日志来分析.

3.在测试库上创建列表(先将以上包含数据字典的日志添加进来):

exec dbms_logmnr.add_logfile('F:\oracle\product\10.1.0\admin\otherdb\log\'dictionary1.ora',dbms_logmnr.new);

4.添加另外的日志文件到列表:

exec dbms_logmnr.add_logfile('F:\oracle\product\10.1.0\admin\otherdb\log\1_267220.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('F:\oracle\product\10.1.0\admin\otherdb\log\.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('F:\oracle\product\10.1.0\admin\otherdb\log\1_267222.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('F:\oracle\product\10.1.0\admin\otherdb\log\1_267223.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('F:\oracle\product\10.1.0\admin\otherdb\log\1_267224.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('F:\oracle\product\10.1.0\admin\otherdb\log\1_267225.dbf',dbms_logmnr.addfile);

5.开始分析日志文件:

在测试库上进行，文件是从正式库拷贝过来的

BEGIN

dbms_logmnr.start_logmnr(DictFileName => 'F:\oracle\product\10.1.0\admin\otherdb\log\dictionary1.ora');

END ;

6.将分析结果转储在表里:

create table logmnr_090415 tablespace users as select * from v$logmnr_contents;

7.结束分析:

exec dbms_logmnr.end_logmnr;

8.日志都分析出来了.那就看看产生这6个日志的2分钟之间.都有人做了什么吧.

select sql_redo,count(*) from logmnr_090415  group by sql_redo order by count(*) desc;

结果吓了一跳.平均1秒就会更新kanbantable 10000笔记录.

那为什么白班的时候没有这种现象呢.带着这个问题及logmnr_090415  中sql_redo的语句去让开发人员分析.很快就得出结论了.原来是有人通过一个触发器对kanbantable这张表做了错误的insert动作.造成了kanbantable这张表中的B班数据大量重复.从而造成了数据的大量重复UPDATE.

问题找到了.原来是表的数据有大量重复.解决方法就简单了.删除这些重复数据就可以了.