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.
问题找到了.原来是表的数据有大量重复.解决方法就简单了.删除这些重复数据就可以了.
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12045182/viewspace-590875/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/12045182/viewspace-590875/