对于DBA来说，面对误操作带来的数据恢复难度，其实很大。主要有以下几个方面：

1. 误操作的影响范围极大，很可能不是删点，改点数据的操作，有时候可能是让人望而兴叹的truncate,drop操作。

2. 数据恢复时需要确认数据损坏的时间点，依此来作为数据恢复的一个基准，该舍弃多少数据，该如何权衡，非常关键。

3. 一旦信息提供错误，是否经得起反复折腾，我想这个对于绝大多数的数据恢复而言，基本都是一锤子买卖，能恢复已经不错了，还要反复恢复。但是一旦出现这种情况，可不能马上乱了阵脚。

灾备方案好不好，一试便知

    自己也听了不少的数据灾难案例，其实备份终于一切这个没错，从逻辑层面还有几个地方需要注意，一个就是权限的入口需要控制，不给你犯错误的权限，能够大大减少犯错误的概率，这个之外的重点就是需要有实战演练，积累经验，做到临危不乱。

    怎么实战呢，我有一次和同事说，数据恢复，备份策略的规划等，很多具体的场景可能有所不同，但是一主两备的核心业务，我小保证数据能够在一定范围内随时恢复，怎么验证备份恢复策略的有效性呢，我也不看你的方案和计划，我就在一个不定的时间点删点数据，truncate操作一下，然后隔一段时间之后告诉你恢复，能恢复回来那就能证明这个方案是可行的。

灾备方案不容忽视

  注意我这里所说的就是一主两备的方案，对于核心业务还是建议这样的方式，备库1和主库在同机房或者同城机房，备库2在异地机房或者同城不同位置的机房，这样能够大大降低出现意外灾害带来的数据灾难。

    防完天灾，看看人祸，人为误操作或者应用错误带来的影响其实影响力要大得多，所以这种情况下，我的一般建议都是在备库2开启闪回数据库，然后保留一定的窗口时间延迟。

开启延迟有下面三种方法,重点推荐方法3，使用DG Broker的方式。

方法1：

alter database recover managed standby database delay 120 disconnect from session;方法2：

alter system set log_archive_dest_3='service=db3 lgwr async delay=120 valid_for=(all_logfiles,all_roles)  db_unique_name=db3'; 

方法3：

DG Broker中设置延迟

edit database xxxx set property DelayMins=180;

没有环境，我们“破坏”环境

当然我们就干脆一些，直接破坏下环境（自己创建数据自己破坏），也总结下经验。

我们在主库端创建数据，然后使用truncate删除，当然这个过程我也不会刻意去记录时间。

create table test_recover(id number,name varchar2(30));

insert into test_recover select level,'obj'||level from dual connect by level<=10; commit; truncate table test_recover;就这么几个步骤就可以完整模拟一个破坏场景，来吧，恢复吧。

而且我也不知道具体的时间，大概就是在晚上九点多快10点操作的。

数据恢复基本步骤

这个时候我们先从备库入手。

DGMGRL> show configuration;

Configuration - dg_accdb1   Protection Mode: MaxPerformance   Databases:     accdb1   - Primary database     saccdb1  - Physical standby database     s2accdb1 - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS因为备库2开启延迟应用，所以我们先取消延迟，使得数据先同步，如果是已有的表drop等操作，延迟应用的优势就出来了。

DGMGRL> edit database s2accdb1 set property DelayMins=0;

Property "delaymins" updated这个备库还是ADG模式

SQL> select open_mode from v$database;

OPEN_MODE -------------------- READ ONLY WITH APPLY我们关闭日志应用。

SQL> recover managed standby database cancel;

Media recovery complete.准备闪回，先把备库置为mount状态

SQL> alter database close;

Database altered.

这个时候问题就来了，我们要闪回到哪个时间点去？

SQL>flashback database to timestamp to_timestamp('xxxxx','yyyy-mm-dd hh24:mi:ss');这个时间点怎么得到呢，一种就是确认，如果确认不了也可以根据应用日志等信息来辅证，当然严谨的方法是我们通过很精确的方式得到，那就是解析日志。

使用LogMiner解析日志

在主库端通过LogMiner解析日志，我写了两个脚本方便调用。

$ cat check_log.sh

sqlplus -s / as sysdba <<EOF set linesize 150 col member format a50 select l.sequence#,l.status ,l.bytes/1024/1024 size_MB,f.member from v\$log l ,v\$logfile f  where l.group#=f.group#; EOF我们通过脚本调用可以看到日志的基本信息，如果是最近的，就可以优先调用看看是否满足。

$ sh check_log.sh

 SEQUENCE# STATUS    SIZE_MB MEMBER ---------- ----------------- --------------------------------------------------        237 CURRENT       500 /U01/app/oracle/oradata/accdb1/redo03.log        236 INACTIVE      500 /U01/app/oracle/oradata/accdb1/redo02.log        235 INACTIVE      500 /U01/app/oracle/oradata/accdb1/redo01.log第二个脚本是使用LogMiner解析日志。

$ cat showlog.sh

sqlplus -s / as sysdba <<EOF execute dbms_logmnr.add_logfile(logfilename=>'$1',options=>dbms_logmnr.new); execute dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog); alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss'; col xid_scn format a30 col username format a10 col timestamp format a20 col sql_redo format a35 col sql_undo format a35 set pages 1500 set linesize 200 select username,xid||':'||scn xid_scn,timestamp,sql_redo,sql_undo from v\$logmnr_contents where  sql_redo not like '%AUD$%'; execute dbms_logmnr.end_logmnr; EOF

调用脚本的结果如下，就这样我会得到一个基本详细的日志解析内容。

$ sh showlog.sh /U01/app/oracle/oradata/accdb1/redo02.log > /tmp/b.log

几乎没有花什么功夫就搜索到了下面的信息，truncate的一个时间点。

UNKNOWN    0A000D00C44E0100:233170277520  2017-02-17 21:58:06  truncate table test_recover;我们根据这个时间点来进行恢复。

在备库端开启闪回数据库，闪回到那个时间点附近，比如提前1秒。

SQL> flashback database to timestamp to_timestamp('2017-02-17 21:58:05','yyyy-mm-dd hh24:mi:ss');过个把分钟就可以轻松搞定，闪回得越早，恢复的时间越长。

如果时间点不满足，可以反复闪回，直到满意为止。

然后我们打开数据库。

SQL> alter database open read only;

Database altered.查看数据的情况就是最开始期望的了。

SQL> select *from cydba.test_recover;

        ID NAME ---------- ------------------------------          1 obj1          2 obj2          3 obj3          4 obj4          5 obj5          6 obj6          7 obj7          8 obj8          9 obj9         10 obj10

恢复后的收尾工作

数据恢复之后，皆大欢喜，我们就可做一些收尾工作，继续开启日志应用。

SQL> alter database close;

Database altered. SQL> alter database open; Database altered.

这个时候日志应用是关闭了，因为之前使用了recover managed standby database cancel的命令。

DGMGRL> show configuration;

Configuration - dg_accdb1   Protection Mode: MaxPerformance   Databases:     accdb1   - Primary database     saccdb1  - Physical standby database     s2accdb1 - Physical standby database       Error: ORA-16766: Redo Apply is stopped Fast-Start Failover: DISABLED Configuration Status: ERROR继续开启日志应用。

DGMGRL> enable database s2accdb1;

Enabled. DGMGRL> show configuration; Configuration - dg_accdb1   Protection Mode: MaxPerformance   Databases:     accdb1   - Primary database     saccdb1  - Physical standby database     s2accdb1 - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS就这样数据库的恢复就告一段落。

有几个细小的问题需要格外注意，一个是主备的时间需要确保同步，如果不同步，闪回就会有潜在问题。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2133759/，如需转载，请注明出处，否则将追究法律责任。