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

本文详述了如何利用ORACLE的日志分析工具DBMS_LOGMNR来追踪数据库事故中执行的操作，包括建立系统对象、设置参数、建立字典、添加事故日志文件、开始日志分析以及终止分析等步骤。通过分析事故机器的日志文件，可以获取到关键操作的SQL语句，从而了解事故发生的具体原因。

前两天有个数据库的生产表在上午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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7177735/viewspace-1141829/