logminer挖掘归档日志,针对DDL误操作的恢复

日志挖掘,未开启补充日志功能,利用归档对DDL操作进行恢复:
        Oracle   的日志文件中,对于表等用户对象(Object),并不是保存名字,而是保存一个ID号。建立字典文件的目的就是使logminer在分析时可以将Object   ID翻译成我们所熟悉的对象名。     
  建立字典文件之前,先要确保数据库的初始化参数   UTL_FILE_DIR   已经正确地设置。
通过命令可以查看是否有字典文件:show parameters utl_file_dir;

[email protected]>show pashow parameters utl_file_dir;
NAME                                     TYPE         VALUE
------------------------------------ ----------- ------------------------------
utl_file_dir                             string         /home/oracle/logminer

可以看到该参数的当前设置。如果没有值,必须修改数据库的init.ora文件,将utl_file_dir   指向一个你想用来保存字典文件的路径。本例中,这里设置   UTL_FILE_DIR=/home/oracle/logminer
(一般的生产数据库是配置好的这个选项)
利用如下语句创建字典文件: 
        begin   sys.dbms_logmnr_d.build(dictionary_filename=>‘dictionary.ora‘,   dictionary_location   =>‘/home/oracle/logminer‘);  end;   -----------dictionary_filename是要生成的字典名,可以随便取                                                                                                                                                                                                     ------------dictionary_location 是要生成字典的位置

[email protected]>begin sys.dbms_logmnr_d.build(dictionary_filename=>‘dictionary.ora‘, dictionary_location =>‘/home/oracle/logminer‘);  end;  
  2  /
PL/SQL procedure successfully completed.<span style="background-color: rgb(255, 255, 255);">                                                                                                                                                                                     </span>

整个创建过程,可能需要十几分钟到一个小时,视该数据库的object   个数以及繁忙程度而定。完成后,会在/home/oracle/logminer目录下看到一个名为dictionary.ora的文件。

[[email protected] logminer]$ pwd
/home/oracle/logminer
[[email protected] logminer]$ ls -rtl
total 40768
-rw-r--r-- 1 oracle oinstall 41742401 May 12 08:43 dictionary.ora

二,   选取要分析的文件     
  日志文件和归档日志文件的数量是非常多的。公司数据库而言,每10分钟要产生一个200M的日志文件,数据量非常之大。因此事实上不可能把所有的日志文件都分析一遍(你要做也行,不过要保证有足够的空间和时间,并且不怕影响数据库性能),通常选取你感兴趣的时间段内的日志进行分析。     
  选取日志文件的操作如下例:     
  begin   sys.dbms_logmnr.add_logfile   (logfilename   =>‘1_47_937825099.dbf‘,   options=>sys.dbms_logmnr.NEW);     
  end; 
  一次只能选取一个文件。若要增加文件,使用下例:     
  begin   sys.dbms_logmnr.add_logfile   (logfilename   =>‘1_48_937825099.dbf‘,   options=>sys.dbms_logmnr.ADDFILE);     
  end;     
      
  若想去掉一个已经选取或增加的文件,使用REMOVEFILE:     
  begin   sys.dbms_logmnr.add_logfile   (logfilename   =>‘1_48_937825099.dbf‘,   options=>sys.dbms_logmnr.REMOVEFILE);     
  end;     
      
  如此反复操作,可以把所有要分析的文件都选取进去。    
  
测试时,使用下边儿的同样可以,而且方便
exec dbms_logmnr.add_logfile(‘/u01/app/oracle/arch/1_36_937825099.dbf‘);

三,   进行分析     
  选取好所有需要分析的文件后,执行下面的命令,开始分析:     
  begin   sys.dbms_logmnr.start_logmnr   (dictfilename   =>‘dictionary.ora‘); end;     
  注意,这里的dictionary.ora就是前面创建的字典文件名。     
  分析过程根据所选取文件的数据量,可能需要几个小时。有时候,DBA可能并不需要这些日志文件中所有的数据,
  那么能否只分析部分数据呢?Oracle 容许你只分析指定时间段或者指定SCN段的数据,语法示例如下:     
  begin   sys.dbms_logmnr.start_logmnr   (dictfilename   =>‘dictionary.ora‘,starttime   =>to_date(‘01-Aug-2001   08:30:00‘,   ‘DD-MON-YYYY   HH:MI:SS‘),endtime   =>   to_date(‘01-Aug-2001   08:45:00‘,   ‘DD-MON-YYYY   HH:MI:SS‘));     
  end;     
  或者 
  begin   sys.dbms_logmnr.start_logmnr   (dictfilename   =>‘dictionary.ora‘,startscn   =>100,endscn   =>500);     
  end;        
  分析结束后,所分析到的数据可以从一个名为   V$LOGMNR_CONTENTS的视图中查询到。我们就可以应用这个视图中的内容来达成目的。
例如,我之前把AIR表中的一行数据误删了,就可以通过如下的语句找回来:
   select username,session#,SESSION_INFO,operation,sql_redo,sql_undo from v$logmnr_contents where  TABLE_NAME=‘AIR‘;

时间: 2025-01-13 06:49:20

logminer挖掘归档日志,针对DDL误操作的恢复的相关文章

rm-rf 误操作的恢复过程

很多DBA一定对rm -rf深恶痛绝吧,没准哪天自己一个犯迷糊就把数据库给消灭了,然后,就没有然后了--那万一--真的发生了这样的不幸,是否真的就无药可救了吗?未必,还是有解决方法的,也许某天当你不幸遇到,就可以用来救自己了.这里做恢复操作的前提是没有可用的rman备份,或者数据库冷备份等,也就是说,没有任何备份. 一.登陆SQLPLUS,并启动数据库 [[email protected] ~]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.1.0

mysql权限的误操作的恢复

mysql权限的误操作的恢复 原因:由于误操作,我把repl用户授予了所有权限,但删除了数据库中的其他用户及权限,因此repl用户虽然具有操作所有数据库的权限,但没有grant权限,所以若想授予其他用户权限,来管理数据库,出现这种状况就酷毙了,没有授予权限怎麽办? 误操作过程: mysql >grant all on *.* to 'repl'@'192.168.1.%' identified by '123456'; mysql> flush privileges; 授予完以后,我把其他的所

【转】SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

4号,公司的生产数据表被全部删除,目前没有找到原因,由于刚接触SQL不久,所以短时间内不会还原,也不敢动被原服务器,于是就将原服务器停掉,拷贝出里面的PPD数据库文件,留作备份:近几天在自己的电脑上尝试修复,一直没有成功,细读了一下<SQL2005技术内幕——存储引擎>了解到删除列.删除表这些操作不会直接对每一行数据进行操作,而是直接改变他们的物理指向地址的ID,专业术语我也不是很清楚,我的理解是这样的,有时间再弄清楚,不过这足以让我明白被删除的表还是存在mdf文件中,其改变的便宜地址记录在日

SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会有更大的灾难.直到你放弃. 解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了.但是唯一遗憾的是,不支持2008及更高版本,这

使用LogMiner查看归档日志

查看归档文件序号select sequence#,first_time from v$log_history order by first_time desc; 查看归档日志大小du -m 归档日志文件 用sql语句确定要分析的归档日志文件select t.first_time,t.name from v$archived_log t order by t.first_time desc; 使用LogMiner分析数据exec sys.dbms_logmnr.add_logfile(logfil

SCPPO:SQL误操作如何恢复?

[前言] 今天研究项目中自己有疑惑的一块儿内容应该是这个系统的核心-数据从上传的Access中解析出来(ETL的贡献)经过一系列的存储过程将数据放到数据库表中(每天凌晨都会定时的执行这一系列操作)这只是今天的引子,不具体深入的讲解下去,小编会在接下来的博文中更加深入的为大家分享: 在分析这块儿的时候无意在服务器上发现一款软件-ApexSQL Log:之前没接触过出于好奇就去网上查了一下它是干嘛用的,这一查不要紧,又燃起了自己新的兴趣,仿佛一切的一切上天冥冥之中自有安排!为何这么说?小编下面为大家

git操作——git pull 撤销误操作,恢复本地代码

需求 开发的代码还未commit到git本地仓库,就从git远程仓库上pull了代码,导致开发的代码直接被冲掉,需要退回到上一个版本代码. 操作 进入到项目git本地仓库文件夹下 打开cmd窗口,执行命令:git reflog 找到需要回退的版本,执行命令:git reset --hard [email protected]{n} 如执行:git reset --hard 61a942c 原文地址:https://www.cnblogs.com/zuiyue_jing/p/11123654.ht

db_recovery_file_dest_size 修改大一点及删除归档日志 |转|

今天给客户测 试问题,让客户把数据发过来了.解压缩后一看,他们还是用的oracle 815版本的(他们exp导出时,带了导出日志,从导出日志中看出来是oracle 815版本的),不过没有关系,低版本的exp是可以用高版本的imp导入到高版本数据库中的.一看是导入还很正常,导入到其中某个表的时候,突然就不动 了.一开始我还没有弄明白怎末回事.后来,无意中看到了 计算机管理--事件查看器中 ,有很多报错信息: Archive process error: ORA-16038: log 1 sequ

MySQL 误操作后如何快速恢复数据~!~!~

基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. 传统解法 用全量备份重搭实例,再利用增量binlog备份,恢复到误操作之前的状态.然后跳过误操作的SQL,再继续应用binlog.此法费时费力,不值得再推荐. 利用binlog2sql快速闪回 首先,确认你的MySQL server开启了binlog,设置了