ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一次归档日志激增的分析. logmnr

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

原创 Linux操作系统 作者:fengjin821 时间:2009-07-31 11:39:12 0 删除 编辑

OS:redhat as 4    ORACLE: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.

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

 

 

 

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

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

注册时间:2009-04-29

  • 博文量
    191
  • 访问量
    511663