Oracle数据库数据丢失？这几种方法教你来恢复~

***数据库数据丢失？这几种方法教你来恢复~

无论是开发、测试还是运维过程中，大家都可能会因为误操作、连错数据库、用错用户、语句条件有误等原因，导致错误删除、错误更新等问题。当你恨不得剁掉按回车的那个指头、捶胸顿足、或者吓得腿软时，肯定希望有办法来恢复这些数据。刚好，*** 提供了一些强大的方法或机制，可以让你找到 “后悔药”。

根据 *** 数据库的特点和提供的工具，主要方法有以下几种方法：

利用逻辑备份使用 import 工具丢失数据的表利用物理备份来通过还原数据文件并进行不完全恢复利用 dbms_logmnr 包从 redo log 文件中恢复利用 flashback 特性恢复数据

为了方便使用方法的介绍，上述恢复方法都将基于以下场景进行：系统管理员在前一天晚上 11 点用 export 对数据库做了全库逻辑备份，然后对所有数据文件进行了热备份。第二天上午 10 点，系统管理员在修改表 TFUNDASSET 的数据时，由于修改语句的条件写错了，导致一批记录(几千条)的 ztm 字段被修改成了错误的值，而且已经提交。这个表是资产表，相对而言数据变化不频繁。

一、利用逻辑备份使用 import 工具恢复丢失的数据

export/import 是 *** 提供的用于对数据库进行逻辑备份的工具。该工具适用于备份那些数据量不大、业务量不多的数据库系统。因为如果在前一天晚上 11 点用 export 做了逻辑备份，那么当今天上午 10 点数据库意外崩溃时，从备份起到数据库崩溃的这段时间里的数据修改操作(包括 DDL 和 DML)都会丢失。如果丢失数据内的表上的数据是相对比较稳定，也就是说该表上基本没有 DML 操作，例如标准代码表、分区表里的历史数据，那么采用 import 来导入该表可以比较完整的恢复数据。如果该表是经常变化的业务表，那么这些丢失的数据只能根据业务情况从纸质记录恢复，或者其他途径恢复。

▲示例如下：这个表是一个资产表。相对来说，今天系统运行中修改的数据较少，丢失的数据量可以承受或者可以从别的途径恢复。那就可以用 import 来恢复。

方法一：

1、把这个表的数据备份到另一个表：

2、删除该表的记录：

3、执行下面的命令：

这个命令中在关键字 tables 中指定需要导入的表名字，ignore=y 表示忽略表已经存在的错误。

4、导入结束后，检查表中的记录，并用适当的方法恢复当天的修改。

方法二：

1、 把需要恢复的表导入到另一个用户下面：

2、检查数据以后，把原表记录删除：

3、然后从另一用户表中插入回去：

4、 数据量比较大时可以采用如下方法：

二、利用物理备份来通过还原数据文件并进行不完全恢复

如果数据库运行在归档模式下，那么可以通过使用以前的数据文件备份进行还原，然后利用归档日志进行前滚，直到回滚到错误操作的时间点前，然后重置日志文件打开数据库。

可以通过下列方法确认是否是运行在归档模式：

如果是如上所示，那么就是运行在归档模式了。

▲假定在前一天晚上 11 点做了全库物理备份，那么可以考虑如下恢复：

1、关闭数据库：

由于数据库的不完全恢复必须在一个关闭的数据库上实施，利用一个旧的数据库的备份还原，然后用日志根据需要逐步前滚，而不能还原一个新的备份，再回退到某个时间点。

通知各客户端数据库将关闭，然后发出：

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

2、确定错误操作的时间：

可以根据操作员的估计来确定不完全恢复需要前滚停止的时间，也可以利用 LogMiner 来分析日志文件(这个工具将在后面介绍)，找出错误操作的准确时间。

3、还原数据文件：

先对当前的数据库文件进行备份，然后再用以前的最近一次备份覆盖现有数据文件。注意：不覆盖现有的控制文件。

4、基于时间点恢复，启动数据库到装配状态：

这样数据库就恢复到了 2015 年 10 月 20 日的 9 点 58 分零秒。

然后再利用业务资料补充这段时间内的数据。

三、利用 dbms_logmnr 包从 log 文件中恢复

这个包是由 *** 提供，与 dbms_logmnr_d 包配合使用可以方便地分析联机日志文件和归档日志文件，从这些日志文件中提取出所有对数据库的更改操作。

在使用这个包之前，需要先做一些设置和修改：

1、打开 initorcl.ora，修改初始化参数 utl_file_dir，设置 dbms_logmnr_d 包将要使用的数据字典文件的放置目录。

然后重启数据库使参数生效。

2、以 sys 用户连接到数据库执行 dbmslmd.sql 脚本重建 dbms_logmnr_d 这个包。

应用 Logminer 分析重做日志文件的操作主要有以下步骤：

使用 dbms_logmnr_d 里的存储过程 build 创建一个外部数据字典文件;使用 dbms_logmnr 里的存储过程 add_logfile 添加要分析的日志文件;使用 dbms_logmnr 里的存储过程 start_logmnr 启动分析;查询与 dbms_logmnr 相关的几个视图来获取日志文件内容;使用 dbms_logmnr 里的存储过程 end_logmnr 结束分析。

▲下面详细讲述使用的过程

1)使用 dbms_logmnr_d 里的存储过程 build 创建一个外部数据字典文件：

2)使用 dbms_logmnr 里的存储过程 add_logfile 添加要分析的日志文件到待分析文件列表：

如果没有运行在归档模式，那么由于重做日志文件的循环使用可能导致日志文件被覆盖而无法获取到所要寻找的恢复条目。如果运行在归档模式，则可以通过查看 $ORACLE_HOME\admin\orcl\bdump 目录下的 alert_orcl.log 里日志文件归档的时间和错误操作的时间来确定加入哪些归档日志文件到待分析的文件列表中去。

注意：执行以上过程时 logfilename 参数需要写日志文件的全路径，否则会报错。重复以上操作直到把所有需要分析的文件都加到列表中去。这样就可以启动进行分析。

3)使用 dbms_logmnr 里的存储过程 start_logmnr 启动分析;

这样就可以通过下面的查询来获取日志文件的内容了。

4)查询与 dbms_logmnr 相关的几个视图来获取日志文件内容;

这样就可以找出要恢复所需的语句。注意：v$logmnr_contents 只对执行 dbms_logmnr.start_logmnr 的会话有效，如果通过其他会话或者使用 dbms_logmnr.end_logmnr 终止了分析，都将不能访问 v$logmnr_contents 的数据。如果要使其他会话也能获取到这些数据，可以通过另外建表来实现，如：

create table undo_sql as select * from v$logmnr_contents。

再对 undo_sql 进行授权，其他用户就可以访问 v$logmnr_contents 的数据了。

5)使用 dbms_logmnr 里的存储过程 end_logmnr 结束分析。

使用完成以后用下面的命令来结束分析活动：exec dbms_logmnr.end_logmnr;

这样就释放了分配给 logminer 的资源(内存和数据结构)。

从上面的过程可知，如果是更新的数据量比较大，而日志文件比较小，就可能会导致日志文件的切换。如果没有及时去挖掘日志文件(没有运行在归档模式)，那么可能会由于日志文件的循环使用而导致数据不可恢复。如果运行在归档模式，也可能由于需要分析的日志文件比较多而时间较长。

四、利用 flashback 新特性恢复数据

使用这个 Flashback Query 特性的前提条件：

1. 数据库必须处于 Automatic Undo Management 状态。

2. ***可以闪回查询的时间段由 UNDO_RETENTION 初始化参数(单位为秒)指定

可以通过 ALTER SYSTEM SET UNDO_RETENTION = ; 来动态修改参数值。

▲如何使用 Flashback Query 来恢复数据呢?

1)通过 SQL

使用 SELECT 语句的 AS OF 来进行闪回查询，语法如下：

使用 AS OF 关键字来对表，视图或者物化视图进行 Flashback Query，如果指定了 SCN，那么 expr 部分必须是一个数字，如果指定了 TIMESTAMP，那么 expr 必须是一个 timestamp 类型的值。查询结果将返回在指定的 SCN 或者时间点上的数据。

下面我们使用 scott 方案来作一个实验。

如果想在 update 的子查询部分使用 AS OF，那么该查询只能返回一条记录，否则将会报错。

可以通过添加一个临时表作为中转，然后再作更新，如下：

2)通过 DBMS_FLASHBACK 包来恢复

DBMS_FLASHBACK 包提供了以下几个函数：

ENABLE_AT_TIME：设置当前 SESSION 的闪回查询时间ENABLE_AT_SYSTEM_CHANGE_NUMBER：设置当前 SESSION 的闪回查询 SCNGET_SYSTEM_CHANGE_NUMBER：取得当前数据库的 SCNDISABLE：关闭当前 SESSION 的闪回查询

当将一个 SESSION 设置为闪回查询模式之后，后续的查询都会基于那个时间点或者 SCN 的数据库状态，如果 SESSION 结束，那么即使没有明确指定 DISABLE，闪回查询也会自动失效。

当 SESSION 运行在闪回查询状态时，不允许进行任何 DML 和 DDL 操作。如果要用 DML 操作来进行数据恢复就必须使用 PL/SQL 游标。

▲示例：

通过上面的例子可以看出，只要这个修改的时间不早于 sysdate- (UNDO_RETENTION 指定的秒数), 就可通过这种方式来恢复数据。

对于问题中的批量数据，可以写个过程来完成获取到更改前的数据：

然后再用这个临时表里的数据来更新 TFUNDASSET 就可以了。

五、总结

比较以上几种恢复数据的方法的使用过程，我们可以看出：

exp/imp 只适合于数据变化不大的表的数据丢失的情况，即使用这种方法处理后也需要从业务办理资料中修正数据，否则导致数据丢失;采用基于时间点的不完全恢复可以恢复丢失的数据，但是需要关关闭数据库，减少系统可用时间，而且也会丢失恢复时间点以后的数据;使用 LogMiner 可以较好的恢复数据，但是要求数据库尽可能运行在归档模式，否则也可能导致数据丢失。好处是不用关闭系统，能够从日志文件中得到所有的数据。使用 Flashback 最方便和简洁，可以直接得到修改前的数据，但是需要依赖系统设置，并且需要占用大量的回滚表空间。

因此选择什么样的方法来恢复数据，取决于你的系统环境和具体情况，不能生搬硬套。采用正确的方法才能***程度的减少数据的丢失。

当然，***是不需要用到这些恢复的办法。前提是，你必须做好以下的工作：

为不同环境创建不同的数据库用户、不同密码(如果不能用户不同，一定要密码不同);将 owner 和应用用户分开，并做适度授权;在做 DML 前，先用同样的条件做查询，看根据结果集是否符合预期。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。