|
如果被人不小心删除了数据库的表对象里面的数据，而我们又不知道准确的操作时间，这时，就可以使用oracle的LOGMNR工具，分析查询数据库的归档日志，从而查询该误操作的内容和时间，有些直接调用LOG_UNDO就可以恢复。
我的操作系统CENT-OS，数据库是oracle11g
1、使用ORACLE用户登录linux，进入$ORACLE_HOME/dbs，找到里面的initSID.ora这个文件，这是数据库启动的参数文件，使用VI工具，手动在里面添加一个参数utl_file_dir='/u01/arch'，utl_file_dir在数据库里默认为空，大家可以使用SHOW PARAMETER UTL来查看系统里是否已经设置过该参数。
或者在启动的SERVER里面使用ALTER来修改该参数。
alter system set utl_file_dir='/u01/arch' scope=spfile;
2、重启服务，让我们刚刚的修改生效。
3、接着，我们来生成用于分析的数据字典
在SQLPLUS里调用数据库的工具包DBMS_LOGMNR_D.BUILD
BEGIN
dbms_logmnr_d.build(
dictionary_name => 'logmnr_dict.dat',
dictionary_location=>'/u01/arch'
);
END;
/
操作完成后，会再/u01/arch里面出现一个名为logmnr_dict.dat的文件。
上面的dictionary_location的地址可以随便设，不过一定要和utl_file_dir的值一样，否则出错。
4、下面我们要做的重启服务，然后装入我们要分析的日志文件。
shutdown immediate
startup mount
下面的操作需要在mount状态下操作
BEGIN
dbms_logmnr.add_logfile(
options=>dbms_logmnr.new,
logfilename=>'/u01/arch/o1_mf_1_37_57scllcl_.arc'
);
END;
/
options是用来指定文件操作:new为添加新的用于分析的日志文件；removefile用来移除不需要分析的日志。
logfilename为需要添加进入分析的日志的文件路径，我这个是把归档的日志文件从flash_recovery_area里面拷贝过来的。
5、再接着我们就要启动分析了
因为使用LOGMNR分析需要些文件，而刚刚我们的SERVER是在MOUNT状态下的，无法写文件，因此我们需要做的是：
alter database open
将数据库的状态修改为OPEN
BEGIN
dbms_logmnr.start_logmnr(
dictfilename => '/u01/arch/logminer_dict.dat',
starttime => to_date('20090808 22:00:00','yyyymmdd hh24:mi:ss'), endtime => to_date('20090808 23:40:00','yyyymmdd hh24:mi:ss') );
END;
/
dictfilename为我们刚刚建立的数据字典文件。
starttime，endtime为分析的时间范围。
如果大家使用PL/SQL DEVELOPER上面的这些过程的调用就不用像我这样还要手动写了。
6、查询日志内容
进过上面的辛苦的工作，下面就是我们收获的时候了，先介绍几个数据字典视图。
v$logmnr_dictionary 显示用来决定对象ID名称的字典文件的信息
v$logmnr_logs 在LogMiner启动时显示被分析的日志列表 v$logmnr_contents LogMiner启动后，可以使用这个视图在sql提示符下输入sql语句来查询重做日志的内容。 select scn ,seq_name,timestamp,seq_owner,operation from v$logmnr_contents where sql_name='your object'
我们可以看到几条关于OBJECT的记录，operation显示的该操作的类型（DDL，DELETE,INSERT,UPDATE），没有SELECT，因为SELECT是不写REDO LOG的（美中不足！！）。
我们如果想看看操作的具体内容可以接着查询：
select scn,sql_redo,sql_undo from v$logmnr_contents where scn='192838718'
就可以显示你要查看的操作的内容，以及它对应的UNDO操作，可以调用SQL_UNDO在ROLLBACK。
OK了....
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhangchu_63/archive/2009/08/09/4427482.aspx
|
|
|
