Oracle 11gR2数据库闪回功能--预防人为逻辑错误

1.Flashback对于DJI ERP系统的作用？

对于一些人为操作的错误，比如批量删除了数据，我们可以通过Flashback功能来恢复。缺点是，此段时间内其他用户的正确操作也会丢失。

a.设立一个闪回窗口，例如60分钟。当出现人为错误时，可以恢复到过去60分钟内的任何一个时间点。

b.以某个时刻设定一个恢复点，以后出问题了，那怕过了几个月，都可以恢复到这个时刻上来。而且，只能恢复到这个时刻，而不能是这几个月内的任何一个时间点。

我们的需求只落在闪回方案b上。

我们可以在生产库或灾备库上开启flashback。

A.利用灾备库做完闪回操作后，我们可以查询相应时刻的表数据，也可以利用这个时刻的静态数据库，克隆出一个新的环境。如果克隆到正式环境，能起到恢复生产的作用。但此时生产停机时间可能就得半天左右了。

B.如果是生产开启flashback，当出现需要全库闪回时，直接就可以在生产闪回了，停机时间会在1小时内。

2.闪回理论参考

理论上，我们都可以闪回到这时间窗口内的任何一个时间点。开了闪回日志，每间隔10分钟，会将有变化data block的变化前影像写到flashback log中（没变化的data block就不会记）。此时能回退的点，取决于FRA中的闪回日志窗口，窗口是随着空间的压力而向后滚动的。鉴于闪回日志是一段时间采样一次，那么我们是否只能闪回到以10分钟为单位的时间点上呢？如果想要10分钟内的时刻怎么办呢？所以flshback database时也是需要用redo log来做精确恢复的。回退的机制是这样的，根据想恢复到的target time，将该target time之前的最接近的一次闪回日志采样数据取出，然后将每个数据块利用redo log向后走到精确地走到target scn。当然，我们有了1440这个保证的时间窗，时间窗中的日志与归档日志都不会被删除、就算它符合归档日志删除策略。

3.方案A的实践指导参考

包括开启闪回功能、以及如何闪回。

在生产库与灾备库上开启闪回都是可以的，方法大同小异，下面介绍在灾备库上开启flashback功能。

1）.通过这个查询，可以知道，我们的ERP生产库、灾备库的闪回功能都是没有开启的。

SQL> select flashback_on from v$database;

FLASHBACK_ON

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

NO

2）.开启flashback功能。当我在DG库想开启闪回功能时，会提示必须先启动闪回恢复区，指定闪回日志应该放到哪里。

SQL> alter database flashback on;

alter database flashback on

*

ERROR at line 1:

ORA-38706: Cannot turn on FLASHBACK DATABASE logging.

ORA-38709: Recovery Area is not enabled.

SQL>

3）.指定flash recovery area（fra,闪回恢复区）。我们设定其size为80G（也就是flashback log、以及存放在fra区的其他文件如归档日志、备份等，不能超过80G），并且把“/u01/erpdg/db/apps_st/fra”这两个路径作为闪回恢复区。

SQL> alter system set db_recovery_file_dest_size=80g;

System altered.

SQL> alter system set db_recovery_file_dest=‘/u01/erpp1/db/apps_st/fra‘;

System altered.

SQL> 

4）.再次开启flashback功能，因为我们的灾备库在实时恢复生产库的日志，所以会报错。我们必须先停下恢复日志的进程、即MRP进程，使得灾备库处于一个静止时间点。

5）.停掉MRP进程：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

6）.再次开启闪回特性，成功了。

7）.此时我们的闪回时间窗口多大呢？通过查看参数db_flashback_retention_target的值，是1440分钟。这个值是可以调整的。这个窗口是随着空间的压力而向后滚动的。也就是说，1440分钟（一天）以内的数据，系统是必须要保证可以闪回到的，假如空间不足以保证1440分钟的闪回，系统宁愿宕下来不运作，也不会让我们不能闪回到。那是不是1440分钟以外的人为错误，我们就一定不能闪回呢？也不一定，假如空间是否足够，两天、三天前的闪回日志，系统依然会保留的。触发系统删除闪回日志的，一般是系统空间压力（比如设定为达到fra的90%就触发删除，删除到60%为止）。

8）.此时我们要将dg库的mrp进程重新启起来，再实时应用生产库传过来的日志。

SQL> alter database recover managed standby database using current logfile disconnect from session parallel 8;

Database altered.

SQL>

此时，整个DG库的flashback功能开启完毕。

9）.闪回查询。当有一天，有用户在数据库里面误操作，比如人为地删除了数据。如果是一个表的数据，其实这里我们首先是可以考虑利用undo的闪回查询。

select * from dept as of timestamp to_timestamp(‘2012-03-09 21:55:06‘,‘yyyy-mm-dd hh24:mi:ss‘);--闪回查询，利用回滚段。 

select * from dept as of timestamp to_timestamp(‘2012-03-09 21:55:06‘,‘yyyy-mm-dd hh24:mi:ss‘) minus select * from dept;--得到被删除的记录

execute SYS.dbms_flashback.enable_at_time(to_timestamp(‘2012-03-09 21:55:06‘,‘yyyy-mm-dd hh24:mi:ss‘));

--让当前会话回到指定时间点，会看到一个冻结版的数据库，只能select，不能DML。

备注：表结构不能被更改过。即闪回不能跨越DDL。

对于闪回查询，就是查询某个表过去的数据。这里，我们先讨论需要整库闪回的情况，比如做了一些错误操作，涉及到很多关联的表，我们也很难理清究竟要闪回什么的时候，就可以用统一的整库闪回操作。

10）.全库flashback前，同样需要停掉MRP进程：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

11）.全库Flash back操作

SQL> flashback database to timestamp to_timestamp(‘2014-07-22 14:22:24‘,‘yyyy-mm-dd hh24:mi:ss‘);

Flashback complete.

SQL> 

12）.验证。此时我们已经闪回到了所需要的时间点。

SQL> alter session set nls_date_format=‘yyyy-mm-dd hh24:mi:ss‘;

Session altered.

SQL> col max(first_time) for a30

SQL> select CONTROLFILE_TIME from v$database;

CONTROLFILE_TIME

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

2014-07-22 14:22:25

SQL> 

13）.反复闪回，以取得错误刚好发生前的时间点。

alter database open read only;

以只读模式打开，看是否找到了被误删除的内容，不断从shutdown abort开始，重新flashback，不断采用二分法，以逼近被删除模式那一刻之前的点。