ITPub博客

首页 > 数据库 > Oracle > 某数据库再次发生所有记录置为3的问题,再用Logminer分析日志文件

某数据库再次发生所有记录置为3的问题,再用Logminer分析日志文件

原创 Oracle 作者:lucy_lxy 时间:2014-04-14 16:10:32 0 删除 编辑
    前两天有个数据库的生产表在上午11点半左右又一次所有记录均被置为3,据说4年前曾发生过一次同样的事情,程序人员和上层都不相信是程序的事情,相关人员信誓旦旦说自己的应用不会有问题,希望察看下相应的操作。可惜的是,事情发生之后,软件人员没有相关的知识,没做任何保护现场的操作,即进行了导入操作(imp默认都是logging的,其主要是create , insert操作,会产生大量的 REDO LOG),数据库又运行在非归档模式,察看传过来的alert文件,联机日志早就切换了3、 40遍了,传过来的联机日志文件最早的事情已经是下午17:20的了,操作早已无影无踪。上层说那么多企业都在使用的应用,怎么偏偏他们家,别人家没有遇到过这种情况,我本人比较持怀疑的态度,怎么这么巧两次都是改为了3 ,应该是某个测试语句,或者某个程序分支有这么条语句忘记注释掉了,结果在满足了一定条件下,就被执行了。

    不过为了让其知道ORACLE 的 logminer 工具能把执行过的操作抓出来,还是分析了下最早的联机日志文件,因为很久没用了,参照的文档是:

http://blog.163.com/angel_yxf/blog/static/115569192008644112615/ 

写的很详细也很实用,在此补充几点。 

对方操作系统是windows 2003,ORACLE 的9206 

启动我的9i虚拟机,注意必须在相同版本的ORACLE分析事故数据库的日志文件。

1.首先执行2个脚本建立所需的系统对象和过程等:

sqlplus /nolog

conn / as sysdba;

@%oracle_home%\rdbms\dbmslm

@%oracle_home%\rdbms\dbmslmd

 

2.接下来在事故机器上察看下参数:

SQL> show parameter utl;

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

create_stored_outlines               string

utl_file_dir                         string

SQL>

如果为空,则要设定下值

SQL>alter system set utl_file_dir='e:\oracle\ora92\logminer' scope=spfile;

重启下数据库:

SQL>Shutdown immediate;

SQL>Startup;

事故机器上该参数是有值的:d:\oracle\logminer

3.执行下列过程,建立字典,需要注意的是,这步必须在事故机器上执行,否则在分析日志文件的时候会提示DBID 虚拟机上的不符:

SQL>exec sys.dbms_logmnr_d.build(dictionary_filename=>'dictionary.ora', dictionary_location =>'e:\oracle\ora92\logminer');

PL/SQL 过程已成功完成。

4.添加事故日志文件,在'd:\redo001'redo01.log

SQL>EXECUTE dbms_logmnr.add_logfile(LogFileName=>'d:\redo01\redo01.log',Options=>dbms_logmnr.new);

PL/SQL 过程已成功完成。

可以一次添加多个文件,但推荐还是一次分析一个,尤其日志文件大于50m的时候。

5.开始进行日志分析:

SQL> EXECUTE dbms_logmnr.start_logmnr(DictFileName=>'e:\oracle\ora92\logminer\di

ctionary.ora');

BEGIN dbms_logmnr.start_logmnr(DictFileName=>'e:\oracle\ora92\logminer\dictionar

y.ora'); END;

*

ERROR 位于第 1 :

ORA-01295: 字典  和日志文件之间的 DB_ID 不匹配

ORA-06512: "SYS.DBMS_LOGMNR", line 53

ORA-06512: line 1

此处必须使用在事故机器上建立的字典文件,而不能使用虚拟机上建立的字典文件。换上事故机器的dictionary.ora,再次执行显示:

PL/SQL 过程已成功完成。

6.察看系统视图V$LOGMNR_CONTENTS,可以使用条件限制你所关心的用户和表相关的操作,如果日志文件很大,结果也会很庞大,最好是限定条件,并将结果SPOOL出去:

spool d:\t_ABC_update.txt

--查询用户为TEST 对其表T_ABC进行操作的语句:

SELECT sql_redo FROM v$logmnr_contents WHERE username='TEST' and instr(sql_redo,'T_ABC')>0 ;

SELECT * FROM v$logmnr_contents WHERE username='TEST' and instr(sql_redo,'T_ABC')>0 ;

 --只查询该表的'UPDATE'操作

SELECT * FROM v$logmnr_contents WHERE username='TEST' and operation='UPDATE' and instr(sql_redo,'T_CJ_ZZSJCJ')>0 ;

--只查询该表的'DELETE'操作

SELECT * FROM v$logmnr_contents WHERE username='TEST' and operation='DELETE' and instr(sql_redo,'T_CJ_ZZSJCJ')>0 ;

--只查询该表的''INSERT '操作

SELECT * FROM v$logmnr_contents WHERE username='TEST' and operation='INSERT' and instr(sql_redo,'T_CJ_ZZSJCJ')>0 ;

Spool off  结束查询。

以下是部分实例输出:

update "TEST"."T_ABC" set "YL_ZF2" = '1' where "YL_ZF2" = '0' and ROWID = 'AAAI6IAAIAABjXoAAK';                                                                                                               

update "TEST"."T_ABC" set "SL" = NULL, "DQJE" = NULL, "CCS" = NULL, "SSSJBJ" = '1', "YL_ZF2" = '1' where "SL" IS NULL and "DQJE" IS NULL and "CCS" IS NULL and "SSSJBJ" = '1' and "YL_ZF2" = '1' and ROWID = 'AAAI6IAAIAABjXoAAK';                                                                                                            

update "TEST"."T_ABC" set "YL_ZF2" = '0' where "YL_ZF2" = '1' and ROWID = 'AAAI6IAAIAABjXoAAK';                                                                                                                                                                                                                                        

其中:sql_redo 是发出的操作,Sql_undo 列是用来恢复的反操作。不足之处是似乎没有登陆的操作员或者机器的相关信息,语句操作的时间。

7.最后,使用过程DBMS_LOGMNR.END_LOGMNR终止日志分析事务,此时PGA内存区域被清除,分析结果也随之不再存在。

 

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

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

注册时间:2010-09-27

  • 博文量
    124
  • 访问量
    353515