logmnr恢复数据

最新推荐文章于 2020-05-12 19:45:33 发布
最新推荐文章于 2020-05-12 19:45:33 发布
阅读量575 收藏
点赞数
分类专栏： oracle备份恢复 文章标签： sql 数据库 oracle null database dictionary
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhuomingwang/article/details/6557753
版权

参考dave的博客

http://blog.csdn.net/tianlesoftware/archive/2011/06/19/6554674.aspx

LogMiner 提供了一个处理重做日志文件并将其内容翻译成代表对数据库的逻辑操作的SQL语句

的过程。LogMiner 运行在Oracle 版本8.1 或者更高版本中。

 

一，如何使用Logminer:

首先查询有没有安装logminer需要的包

 

select *

from dba_objects

where object_type='PACKAGE'

and object_name in('DBMS_LOGMNR','DBMS_LOGMNR_D');

 

如果没有要先安装logminer 的两个包；以SYS 用户运行下面两个脚本,其中第一个脚本

dbmslm.sql 用来创建DBMS_LOGMNR 包，该包用来分析日志文件。第二个脚本dbmslmd.sql 用来

创建DBMS_LOGMNR_D 包，该包用来创建数据字典文件

这两个包在($ORACLE_HOME/rdbms/admin下)

 

二，创建数据字典文件

数据字典文件是一个文本文件，使用包DBMS_LOGMNR_D 来创建，如果我们要分析的数据

库中的表有变化(比如表结构有变化等)，影响到库的数据字典也发生变化。另外一种情况是在分

析另外一个数据库文件的重做日志时，也必须要重新生成一遍被分析数据库的数据字典文件。

首先需要修改参数UTL_FILE_DIR ,该参数值为服务器中放置数据字典文件的目录，我

们通过动态修改参数的方式来修改，然后重新启动数据库生效。其中logs_utl_file 目录先期建立

好。

SQL> alter system set UTL_FILE_DIR='D:/logmnr' scope=spfile;

系统已更改。

 

SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup

ORACLE 例程已经启动。

Total System Global Area 167772160 bytes

Fixed Size 1295608 bytes

Variable Size 125831944 bytes

Database Buffers 33554432 bytes

Redo Buffers 7090176 bytes

数据库装载完毕。

数据库已经打开。

 

SQL> show parameter utl_file_dir;

 

NAME                                 TYPE        VALUE

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

utl_file_dir                         string      D:/logmnr

 

然后创建数据字典文件：

BEGIN

dbms_logmnr_d.build(

dictionary_filename => 'logmin_dict.ora',

dictionary_location => 'D:/logmnr');

END;

/

OK ,可以看到在logmnr中已经生成了logmin_dict.ora 数据字典文件。数据字典文件是可以

打开的文本文件。有兴趣可以打开看看。

 

 

三、补充日志（supplemental logging）

 

先看一下补充日志都包含哪些信息和特性：

 

 

（1）索引簇、链行和迁移行；

 

（2）直接路径插入；

 

（3）摘取LogMiner字典到重做日志；

 

（4）跟踪DDL；

 

（5）生成键列的SQL_REDO和SQL_UNDO信息；

 

（6）LONG和LOB数据类型。

 

这里我们重点看一下：track DDL 和 generate sql_redo and sql_undo.

 

Oracle 的online redo 会记录DB的所有操作，包括DDL 和 DML。 supplemental log支持track DDL。

也就是说，我们可以直接去Mining DML的内容。 但是如果要去Mining DDL 内容，

就必须先启动supplemental log，oracle 收集有关更多的DDL 信息之后，我们才可以去Mining它的信息。

因为我们可以根据归档和online redo 去恢复数据，所以这些DDL 的内容，即使不启动 supplemental log，

对与Oracle 内部来说肯定是可以识别的，只是我们不能Mining出来。 只有启动supplemental log之后，我们也就可以Mining出来了。

默认情况下Oracle 并没有启动supplemental log。因为记录太多的内容会增加写log的压力。

SQL_REDO 和 SQL_UNDO 是我们操作的SQL（DDL和DML）和用于回滚的SQL。 我们的恢复就是使用SQL_UNDO 来进行的。

在我们的DML 和DDL操作之前，需要先启动supplemental log。 不然生成的SQL_REDO 和 SQL_UNDO 是没有经过数据字典转换过的，

这样不具可读性。 都是Oracle 内部的ID。

 

启动supplemental log：

 

SQL>alter database add supplemental log data;

 

关闭supplemental log：

 

SQL>alter database drop supplemental log data;

 

查看 supplemental log：

 

SQL>select supplemental_log_data_min from v$database;

 

 一般生产环境不会启动supplemental log。 所以用Logminer 方法来做数据恢复不是一种常用的方法。

 对于DML 操作，还是有一定的可行性。 DDL 就不行。

 

而且在没有启动supplemental log的情况下，Mining出来的SQL_REDO和SQL_UNDO数据是没有进过数据字典进行转换的，可读性很差。如：

 

 

 

delete from "UNKNOWN"."OBJ# 54173"

where "COL 1" = HEXTORAW('53434f5454') and "COL 2" = HEXTORAW('504b5f44455054')

and "COL 3" IS NULL and "COL 4" = HEXTORAW('c3060c30') and "COL 5" = HEXTORAW('c3060c30')

and "COL 6" = HEXTORAW('494e444558') and "COL 7" = HEXTORAW('7869061e14303a')

and "COL 8" = HEXTORAW('7869061e14303a') and "COL 9" = HEXTORAW('323030352d30362d33303a31393a34373a3537')

and "COL 10" = HEXTORAW('56414c4944') and "COL 11" = HEXTORAW('4e') and "COL 12" = HEXTORAW('4e')

and "COL 13" = HEXTORAW('4e') and ROWID = 'AAANOdAABAAATEmAAc';

 

 

 

insert into "UNKNOWN"."OBJ# 54173"("COL 1","COL 2","COL 3","COL 4","COL 5","COL 6","COL 7","COL 8","COL 9","COL 10","COL 11","COL 12","COL 13") values (HEXTORAW('53434f5454'),HEXTORAW('504b5f44455054'),NULL,HEXTORAW('c3060c30'),HEXTORAW('c3060c30'),HEXTORAW('494e444558'),HEXTORAW('7869061e14303a'),HEXTORAW('7869061e14303a'),HEXTORAW('323030352d30362d33303a31393a34373a3537'),HEXTORAW('56414c4944'),HEXTORAW('4e'),HEXTORAW('4e'),HEXTORAW('4e'));

 

启动supplemental log：

 

SQL>alter database add supplemental log data;

 

查看 supplemental log（不需重启数据库）

SQL> select supplemental_log_data_min from v$database;

 

SUPPLEME

--------

YES

 

--假如scott用户对自己的表做了些误操作。

SQL> conn scott/tiger@primary;

SQL> delete from emp where deptno=10;

 

已删除3行。

 

SQL> commit;

 

提交完成。

 

SQL> update emp set ename='aspen' where deptno=20;

 

已更新5行。

 

SQL> commit;

 

提交完成。

 

 

--利用sys对日志进行分析，（当然做这些误操作的日志一定要有，如果这期间日志归档了，也要把

相应的归档日志进行分析）

SQL> conn / as sysdba;

已连接。

SQL> exec dbms_logmnr.add_logfile(logfilename=>'D:/oradata/primary/redo01.log',o

ptions=>dbms_logmnr.new);

 

PL/SQL 过程已成功完成。

 

SQL> exec dbms_logmnr.add_logfile(logfilename=>'D:/oradata/primary/redo02.log',o

ptions=>dbms_logmnr.addfile);

 

PL/SQL 过程已成功完成。

 

SQL> exec dbms_logmnr.add_logfile(logfilename=>'D:/oradata/primary/redo03.log',o

ptions=>dbms_logmnr.addfile);

 

PL/SQL 过程已成功完成。

 

添加归档日志的方法一样，只是logfilename参数的值不同而已.例如：

SQL> exec dbms_logmnr.add_logfile(logfilename=>'D:/app/263370/flash_recovery_are

a/PRIMARY/ARCHIVELOG/ARC00108_0753443662.001',options=>dbms_logmnr.addfile);

 

PL/SQL 过程已成功完成。

 

如果你觉得不需要分析已经在列表中的在线或归档日志，可以通过removefile 命令删除：

SQL> execute dbms_logmnr.add_logfile(logfilename=>'D:/app/263370/flash_recovery_are

a/PRIMARY/ARCHIVELOG/ARC00108_0753443662.001', options=>dbms_logmnr.removefile);

PL/SQL 过程已成功完成。

 

SQL> exec dbms_logmnr.start_logmnr(dictfilename=>'D:/logmnr/logmin_dict.ora');

 

PL/SQL 过程已成功完成。

 

--注意logminer分析出来的保存在v$logmnr_contents里的结果只对当前会话有效

--如果想要保存这些信息的话可以重新建立一个表，把这些信息保存到新表中

SQL> select sql_redo,sql_undo

  2  from v$logmnr_contents

  3  where seg_name='EMP' and seg_owner='SCOTT'

  4  order by timestamp desc;

 

SQL_REDO                                                                       

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

SQL_UNDO                                                                        

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

update "SCOTT"."EMP" set "ENAME" = 'aspen' where "ENAME" = 'SMITH' and ROWID = '

AAAQ+jAAEAAAAAeAAA';                                                            

update "SCOTT"."EMP" set "ENAME" = 'SMITH' where "ENAME" = 'aspen' and ROWID = '

AAAQ+jAAEAAAAAeAAA';                                                           

                                                                                

update "SCOTT"."EMP" set "ENAME" = 'aspen' where "ENAME" = 'ADAMS' and ROWID = '

AAAQ+jAAEAAAAAeAAK';                                                           

update "SCOTT"."EMP" set "ENAME" = 'ADAMS' where "ENAME" = 'aspen' and ROWID = '

AAAQ+jAAEAAAAAeAAK';                                                           

 

SQL_REDO                                                                       

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

SQL_UNDO                                                                       

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

                                                                               

update "SCOTT"."EMP" set "ENAME" = 'aspen' where "ENAME" = 'SCOTT' and ROWID = '

AAAQ+jAAEAAAAAeAAH';                                                           

update "SCOTT"."EMP" set "ENAME" = 'SCOTT' where "ENAME" = 'aspen' and ROWID = '

AAAQ+jAAEAAAAAeAAH';                                                           

                                                                               

update "SCOTT"."EMP" set "ENAME" = 'aspen' where "ENAME" = 'FORD' and ROWID = 'A

AAQ+jAAEAAAAAeAAM';                                                            

update "SCOTT"."EMP" set "ENAME" = 'FORD' where "ENAME" = 'aspen' and ROWID = 'A

 

SQL_REDO                                                                        

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

SQL_UNDO                                                                       

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

AAQ+jAAEAAAAAeAAM';                                                            

                                                                               

update "SCOTT"."EMP" set "ENAME" = 'aspen' where "ENAME" = 'JONES' and ROWID = '

AAAQ+jAAEAAAAAeAAD';                                                           

update "SCOTT"."EMP" set "ENAME" = 'JONES' where "ENAME" = 'aspen' and ROWID = '

AAAQ+jAAEAAAAAeAAD';                                                            

                                                                               

delete from "SCOTT"."EMP" where "EMPNO" = '7934' and "ENAME" = 'MILLER' and "JOB

" = 'CLERK' and "MGR" = '7782' and "HIREDATE" = TO_DATE('23-1月 -82', 'DD-MON-RR

 

SQL_REDO                                                                        

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

SQL_UNDO                                                                       

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

') and "SAL" = '1300' and "COMM" IS NULL and "DEPTNO" = '10' and ROWID = 'AAAQ+j

AAEAAAAAeAAN';                                                                 

insert into "SCOTT"."EMP"("EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","D

EPTNO") values ('7934','MILLER','CLERK','7782',TO_DATE('23-1月 -82', 'DD-MON-RR'

),'1300',NULL,'10');                                                           

                                                                                

delete from "SCOTT"."EMP" where "EMPNO" = '7839' and "ENAME" = 'KING' and "JOB"

= 'PRESIDENT' and "MGR" IS NULL and "HIREDATE" = TO_DATE('17-11月-81', 'DD-MON-R

R') and "SAL" = '5000' and "COMM" IS NULL and "DEPTNO" = '10' and ROWID = 'AAAQ+

 

SQL_REDO                                                                       

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

SQL_UNDO                                                                        

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

jAAEAAAAAeAAI';                                                                

insert into "SCOTT"."EMP"("EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","D

EPTNO") values ('7839','KING','PRESIDENT',NULL,TO_DATE('17-11月-81', 'DD-MON-RR'

),'5000',NULL,'10');                                                           

                                                                               

delete from "SCOTT"."EMP" where "EMPNO" = '7782' and "ENAME" = 'CLARK' and "JOB"

 = 'MANAGER' and "MGR" = '7839' and "HIREDATE" = TO_DATE('09-6月 -81', 'DD-MON-R

R') and "SAL" = '2450' and "COMM" IS NULL and "DEPTNO" = '10' and ROWID = 'AAAQ+

jAAEAAAAAeAAG';                                                                 

 

SQL_REDO                                                                       

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

SQL_UNDO                                                                        

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

insert into "SCOTT"."EMP"("EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","D

EPTNO") values ('7782','CLARK','MANAGER','7839',TO_DATE('09-6月 -81', 'DD-MON-RR

'),'2450',NULL,'10');                                                          

                                                                               

 

已选择8行。

 

通过sql_undo我们就可以恢复相应的数据了，order by timestamp desc;

这个很重要哦，我们的通过sql_undo得到的sql语句要按照时间从后往前执行

 

 

SQL> exec dbms_logmnr.end_logmnr;

 

PL/SQL 过程已成功完成。

真的不知道取什么名
关注
专栏目录
[Logmnr]使用logminer找回被误删的数据
不忘初心、方得始终
11-13 1992
LogMiner日志挖掘技术在有些时候可以被比作是命悬一线的救命稻草,比方说误删除数据(如delete执行不当),可以通过LogMiner挖掘日志文件将这些数据补插回来 使用LogMiner预览:LogMiner的原理就是找出日志文件(redo file),所对应的UNDO.如你新增1W行数据,在redo里以insert形式体现,对应的undo即为deleteLogMiner所有操作
oracle数据恢复，重点介绍通过日志分析LOGMNR工具恢复的方法
spt_dream的博客
12-21 888
背景，业务数据表被删除8天后发现丢失，里面数据很重要。通过每天的数据备份包找到了10号的数据，但是有5条数据11号备份前就没了。所以找不到了。 第一种，备份文件找不到 第二种，闪回方法查询，找不到，因为查询查过了五天，找不回。 第三种，最后成功解决了。通过查询解析日志找回。 第二种回退回滚脚本这里介绍下，没准你的数据就能找回了。 select * from GZYY02 as of timestamp to_timestamp('2019-06-24 20:10:38', 'yyyy-mm-dd
使用Logmnr恢复误删的数据
csdn15515085103的博客
09-22 150
1. 确认测试表T1当前的记录数SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';会话已更改。SQL> select count(*) fr...
利用LOGMNR恢复DELETE的数据
xiaofan23z的专栏
04-21 1786
利用LOGMNR恢复DELETE的数据  (2011-07-31 13:20:44) ▼ 测试如下： create table ta.test3 as select * from user_objects; select count(*) from ta.test3; delet ta.test3; commit; 1、假设由于时间的问题，用闪回报错
logmnr 恢复数据
cishanchun2997的博客
01-27 97
使用 logmnr 恢复 delete table 的数据，truncate 与 drop 的数据需要用备份恢复[@more@]用来恢复 delete 删除的数据测试delete zz 表 (数据5207条)准备工作 查找当时的...
Oracle logmnr挖掘DDL语句实现误删除表的恢复
dbhang的博客
05-12 947
当时一个同事在公司业务统计库上误删除了一个表，下午做业务统计，突然这个表查不到，领导说需要恢复，给我一天时间，让我将这个表恢复，数据库可以申请停机时间。 当时存在的备份： 昨天的手工备份，归档日志都在，当前日志也正常。 模拟恢复场景： Drop purge操作。 数据库正在运行。 无法执行闪回drop，因为使用purge，直接跳过回收站。 由于没有使用RMAN备份，所以不能使用基于表空间的不完全恢复。 恢复计划： 需要挖掘出drop表的时间点/scn 这个是最主要的，然后使用昨天的备份进行不完全恢复，然后将
Oracle数据库数据丢失恢复的几种方法总结
09-09
Oracle数据库在面临数据丢失问题时提供了多种恢复策略，旨在帮助用户在遭遇误操作或系统故障后尽可能地恢复数据。以下是对这些恢复方法的详细说明： 1. **利用逻辑备份使用import工具恢复丢失的数据** 当数据量较...
oracle使用logmnr找回误删数据.rar
01-09
在这种情况下，Oracle的Log Miner（日志分析工具，简称logmnr）提供了一种有效的方法来恢复这些丢失的数据。本文将详细介绍如何利用logmnr找回误删数据。 首先，了解logmnr的基本概念。Log Miner是Oracle数据库内置...
LogMiner---客户的一次疏忽，DBA的一次噩梦。
在路上
04-03 664
客户的一次疏忽，DBA的一次噩梦。 · 作者 小荷||【转载时请务必以超链接形式标明文章原始出处和作者信息】 · 永久链接: http://www.oracleblog.org/working-case/dba-always-bad-luck-with-careless-customer/ 今晚接到老大的电话，泰国的客户不小心删除了一些表的数据，现在非常着急，需要恢复数
使用LOGMNR恢复已提交的数据
congpi2096的博客
10-27 156
使用LOGMNR恢复已提交的数据 1、安装LOGMNR 以as sysdba运行以下两个脚本： $ORACLE_HOME/rdbms/admin/dbmslm.sql; $ORACLE_HOME/rdbm...
通过logmnr工具实现数据恢复
Ping的专栏
04-16 578
最近接到的case.接到客户报障，xxx数据库的一个关键表数据被误删除了，需要做紧急数据恢复。接到客户报障后，随后联系了开发商的工程师。 一.问题分析,经过与局方和开发商的讨论，以及根据系统情况，了解到如下信息。 1.误删除的表名为EMP用户下的EPM_PRO_WORK开头的表名 2.误删除的数据是该表的部分记录。 3.通过delete方式删除，误删除时间大概上午在9:00至1
利用闪回、logmnr找回误删除的数据
要么数一数二，要么不三不四。
10-25 139
朋友遇到了非常经典的ORACLE事故——误删除，开发人员告诉他，昨天下午五点-六点不小心误删了几条数据，问是否可以恢复，朋友的环境是ORACLE 10gR2，没有备份，但有开归档和闪回，这个是可以找回数据的。以下为找回误删除数据的实验。SQL> create table t1(id number,name varchar2(20));Table createdSQL> insert i...
ORACLE LOGMNR简单而强大的工具
茄肥猫的窝
11-14 3286
LOGMNR简单而强大的工具 在Oracle数据库中，LGWR进程将数据库中进行的DML等操作信息记录在日志文件中，在归档模式下，日志文件还会写出到归档日志文件中。在数据库发生故障崩溃后，恢复时数据库可以根据日志信息来重演事务，完成恢复，从而保证成功提交的事务不丢失。 很多第三方工具以及Oracle的一些工作，都可以通过解析日志文件来实现数据复制和同步。Oracle随数据库软件提供了一
LogMiner救命稻草_找回误删除数据
Robo's Blog【海阔凭鱼跃,天高任鸟飞】
01-10 1048
LogMiner日志挖掘技术在有些时候可以被比作是命悬一线的救命稻草,比方说误删除数据(如delete执行不当),可以通过LogMiner挖掘日志文件将这些数据补插回来 使用LogMiner预览: o LogMiner的原理就是找出日志文件(redo file),所对应的UNDO.如你新增1W行数据,在redo里以insert形式体现,对应的undo即为delete o LogMiner所有
oracle使用闪回技术还原表数据。
kai27ks的专栏
03-31 5170
强大的ORACLE10G开始有一个东西叫闪回：flashback技术。它支持还原一定时间内的数据。包括整个数据库，表等。    在演示前确认以下几点：           1、用户有对dbms_flashback包有执行权限！----若没有 grant execute on dbms_flashback to username                      2、进行闪回查询必须设
Oracle Logminer 做数据恢复 说明示例
热门推荐
David Dai -- Focus on Oracle
06-19 1万+
在IBM DBA 小荷的blog上看到一个用Logminer 做数据恢复的例子。 虽然对Logminer 也了解一点，但是用Logminer 做恢复还真没用过，所以也测试一下。 原文链接地址如下：        客户的一次疏忽，DBA的一次噩梦       http://www.oracleblog.org/working-case/dba-always-bad-l
ORA-01346: LogMiner processed redo beyond specified reset log scn
cuixie2370的博客
11-04 103
先介绍一下标题中的错误是怎么发生的。因为一个BUG，ORACLE提供了一个更新数据字典的解决方案，但是需要更新后ABORT数据库并重启。不能确定ORACLE提供的方案是否靠谱，ORACLE也推荐先使用现有的备份恢...
逻辑 STANDBY ORA-00368日志应用失败处理一例
weixin_34179762的博客
07-26 207
故障现象：逻辑STANDBY数据库注册日志成功，但应用日志出现错误，提示“ORA-00368: checksum error in redo log block”，显然是文件受到了破坏。 Tue Jul 24 08:25:59 2012 LOGMINER: WARNING: error 368 encountered, failed to read corrupt logfile /archi...
Oracle复习：关键进程与数据恢复工具Logmnr详解
- **数据恢复**：当无法使用闪回功能时，Logmnr可以帮助找回丢失的数据，前提是存在归档日志。 - **数据库变化跟踪与回退**：Logmnr支持离线分析，对数据库更改进行跟踪，以便于回退到特定时间点，减少点对点恢复的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值