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这个参数呢.此参数为静态参数.生产库是没办法停机重启的.所以就想到了将日志移至测试库(与生产库环境是相同的)进行分析.以下就是在测试环境下的分析过程.

1.创建正式库数据字典文件到归档日志中,并找出是哪个日志,将它拷贝至测试库.

execute DBMS_LOGMNR_D.BUILD(options=>DBMS_LOGMNR_D.store_in_redo_logs);

SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES';

SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END='YES';

我这里得出的归档日志是1_268157.dbf.

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

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

exec dbms_logmnr.add_logfile('/home/oracle/logminer/1_268157.dbf',dbms_logmnr.new);

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

exec dbms_logmnr.add_logfile('/home/oracle/logminer/1_267220.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('/home/oracle/logminer/1_267221.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('/home/oracle/logminer/1_267222.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('/home/oracle/logminer/1_267223.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('/home/oracle/logminer/1_267224.dbf',dbms_logmnr.addfile);

exec dbms_logmnr.add_logfile('/home/oracle/logminer/1_267225.dbf',dbms_logmnr.addfile);

5.开始分析日志文件:

EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS);

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.

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