Oracle 10g闪回

Oracle 10g的闪回

　　与Oracle 9i相比Oracle 10g的Flashback有了非常大的改进，从普通的Flashback Query发展到了多种形式，主要表现在如下几方面新特性：

　　1、Flashback Database

　　Oracle Flashback Database特性允许通过SQL语句Flashback Database语句，让数据库前滚到当前的前一个时间点或者SCN，而不需要做时间点的恢复。闪回数据库可以迅速将数据库回到误操作或人为错误的前一个时间点，如Word中的"撤消"操作，可以不利用备份就快速的实现基于时间点的恢复。Oracle通过创建新的Flashback Logs（闪回日志），记录数据库的闪回操作。如果希望能闪回数据库，需要设置如下参数：

DB_RECOVER_FILE_DEST日志的存放位置，DB_RECOVER_FILE_DEST_SIZE恢复区的大小。在创建数据库的时候，Oracle将自动创建恢复区，但默认是关闭的，需要执行alter database flashback on命令。

　　例：执行Flashback Database命令格式.

SQL>flashback database to time to_timestamp(xxx);

SQL>flashback database to scn xxx

　　2、Flashback Table

　　Oracle Flashback Table特性允许利用Flashback Table语句，确保闪回到表的前一个时间点。与Oracle 9i中的Flashback Query相似，利用回滚段信息来恢复一个或一些表到以前的一个时间点（一个快照）。要注意的是，Flashback Table不等于Flashback Query，Flashback

Query仅仅是查询以前的一个快照点而已，并不改变当前表的状态，而Flashback Table将改变当前表及附属对象一起回到以前的时间点。

　　语法：

flashback table tablename to timestamp xxx或

flashback table tablename to scn xxx

　　注意：如果需要闪回一个表，需要以下条件：

　　•需要有flashback any table的系统权限或者是该表的flashback对象权限；

　　•需要有该表的select,insert,delete,alter权限；

•必须保证该表row movement。

一般情况下，分区表的分区字s段的值是不应该修改的，如果这个值发生变化，则有可能使这条记录不再符号当前分区的分区条件，会使这条记录转移到其他分区中，物理位置（ROWID）会相应变化。

Oracle提供了ENABLE ROW MOVEMENT语句，增加了分区的功能，允许修改分区列，允许记录转移到其他分区，且Oracle会自动维护索引。

虽然，Oracle提供的这个功能很方便，但是也会带来相应的副作用——ROWID不可避免的要发生变化。其中最直接的影响就是LOGMINER，这种发生了ENABLE ROW MOVEMENT的操作，将无法使用LOGMINER中的SQL_UNDO来进行恢复。

具体情况来看下面的例子：

 

 

SQL> CREATE TABLE TEST_PART (ID NUMBER) PARTITION BY RANGE (ID)
  2  (PARTITION P1 VALUES LESS THAN (100), PARTITION P2 VALUES LESS THAN (MAXVALUE))
  3  ENABLE ROW MOVEMENT;

表已创建。

SQL> INSERT INTO TEST_PART VALUES (20);

已创建 1 行。

SQL> INSERT INTO TEST_PART VALUES (20);

已创建 1 行。

SQL> COMMIT;

提交完成。

SQL> COL MEMBER FORMAT A70
SQL> SELECT * FROM V$LOGFILE;

    GROUP# STATUS  TYPE    MEMBER
---------- ------- ------- ---------------------------------------
         3 STALE   ONLINE  F:ORACLEORADATATEST4REDO03.LOG
         2 STALE   ONLINE  F:ORACLEORADATATEST4REDO02.LOG
         1         ONLINE  F:ORACLEORADATATEST4REDO01.LOG

SQL> ALTER SYSTEM SWITCH LOGFILE;

系统已更改。

SQL> SELECT * FROM V$LOGFILE;

    GROUP# STATUS  TYPE    MEMBER
---------- ------- ------- ----------------------------------------
         3 STALE   ONLINE  F:ORACLEORADATATEST4REDO03.LOG
         2         ONLINE  F:ORACLEORADATATEST4REDO02.LOG
         1         ONLINE  F:ORACLEORADATATEST4REDO01.LOG

SQL> UPDATE TEST_PART SET ID = 120 WHERE ROWNUM = 1;

已更新 1 行。

SQL> COMMIT;

提交完成。

SQL> ALTER SYSTEM SWITCH LOGFILE;

系统已更改。

SQL> SELECT * FROM V$LOGFILE;

    GROUP# STATUS  TYPE    MEMBER
---------- ------- ------- --------------------------------------
         3         ONLINE  F:ORACLEORADATATEST4REDO03.LOG
         2         ONLINE  F:ORACLEORADATATEST4REDO02.LOG
         1         ONLINE  F:ORACLEORADATATEST4REDO01.LOG

SQL> EXEC SYS.DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => 'F:ORACLEORADATATEST4REDO02.LOG', -
> PTIONS => SYS.DBMS_LOGMNR.NEW)

PL/SQL 过程已成功完成。

SQL> EXEC SYS.DBMS_LOGMNR.START_LOGMNR(OPTIONS => SYS.DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG)

PL/SQL 过程已成功完成。

SQL> SELECT SQL_UNDO, SQL_REDO FROM V$LOGMNR_CONTENTS;

SQL_UNDO
------------------------------------------------------------------
SQL_REDO
------------------------------------------------------------------

set transaction read write;

update "YANGTK"."TEST_PART" set "ID" = '20' where "ID" = '120' and ROWID = 'AAAB5OAAFAAAAegAAA';
update "YANGTK"."TEST_PART" set "ID" = '120' where "ID" = '20' and ROWID = 'AAAB5OAAFAAAAegAAA';

insert into "YANGTK"."TEST_PART"("ID") values ('120');
delete from "YANGTK"."TEST_PART" where "ID" = '120' and ROWID = 'AAAB5OAAFAAAAegAAA';

delete from "YANGTK"."TEST_PART" where "ID" = '120' and ROWID = 'AAAB5PAAFAAAAeoAAA';
insert into "YANGTK"."TEST_PART"("ID") values ('120');

commit;

SQL> exec sys.dbms_logmnr.end_logmnr

PL/SQL 过程已成功完成。

SQL> delete from "YANGTK"."TEST_PART" where "ID" = '120' and ROWID = 'AAAB5PAAFAAAAeoAAA';

已删除 1 行。

SQL> insert into "YANGTK"."TEST_PART"("ID") values ('120');

已创建 1 行。

SQL> update "YANGTK"."TEST_PART" set "ID" = '20' where "ID" = '120' and ROWID = 'AAAB5OAAFAAAAegAAA';

已更新0行。

可以看到，一个UPDATE语句被ORACLE拆成了三条语句。首先是对当前的记录进行更新（指定ROWID），第二步删除指定ROWID的记录，第三步用更新后的值重新插入记录。执行完第三步，新的记录已经插入到分区P2中了。

如果按照相反的顺序执行SQL_UNDO，却发现无法恢复到以前的状态。首先删除分区P2中的记录，这没有问题。第二步，插入新的记录，这里已经有问题了，插入时无法指定ROWID，记录仍然会插入到P2分区中。最后进行更新，这是指定的ROWID是P1分区中的ROWID，这个ROWID在当前根本就不存在，因此，已经无法恢复到原来的状态了。

 

　　例：执行将test表闪回到2005年5月7日下午3点。

SQL>flashback table test to timestamp to_timestamp(’2005-05-07 15:00:00’,’yyyy-mm-dd hh24:mi:ss’);

　　3、Flashback Drop

　　Oracle Flashback Drop特性提供一个类似回收站的功能，用来恢复不小心被删除的表。当删除表时，Oracle 10g并不立刻释放被删除的表所占用的空间，而是将这个被删除的表进行自动重命名（为了避免同类对象名称的重复）并放进回收站中。所谓的回收站类似于Windows系统中的回收站，是一个虚拟的容器，用于存放所有被删除的对象，在回收站中被删除的对象将占用创建时的同样的空间。如果这个被删除的表需要

进行恢复，就可利用Flashback Drop功能

　　例：进行一个删除表后恢复的简单测试。

　　（1）显示回收站信息

SQL>show recyclebin;

　　可以看到，回收站中是没有任何结果的，表示没有任何表在回收站中。

　　（2）创建一个表，并删除，再次显示回收站信息

SQL>create table test_drop(name varchar2(10));

SQL>drop table test_drop;

SQL>show recyclebin;

ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME

TEST_DROP BIN$b+XkkO1RS5K10uKo9BfmuA==$0 TABLE 2005-05-07:14:30:47

　　（3）对被删除的表进行恢复

SQL>flashback table test  to before drop;或

SQL>flashback table "BIN$b+XkkO1RS5K10uKo9BfmuA==$0" to before drop;

　　（4）管理回收站

　　清除回收站中的单个表：purge table test_drop

　　清除整个回收站：purge recyclebin

　　清除不同的对象回收站：purge user_recyclebin或purge dba_recyclebin

　　（5）确认删除一个表

SQL>drop table test_drop purge;

　　如果删除一个表且不放到回收站中不能进行恢复，在drop语句中可以利用purge选项。

　　4、Flash Version Query

　　Oracle Flashback Version Query特性，利用保存的回滚信息，可以看到特定的表在时间段内的任何修改，如电影的回放一样，可以了解表在该期间的任何变化。Flashback version query一样依赖于AUM，提供了一个查看行改变的功能，能找到所有已经提交了的行的记录，分析出过去时间都执行了什么操作。Flashback version query采用VERSIONS BETWEEN语句来进行查询，常用的方法：

　　•VERSIONS_SCN - 系统改变号

　　•VERSIONS_TIMESTAMP - 时间

　　例如：在test表中，时间1插入一条记录，时间2删除了这条记录，对于时间3执行select * from test当然查询不到这条记录，只能看到该表最后的提交记录。这时如果利用Flash Table或者是Flash Query，只能看到过去的某一时间点的一个快照，而利用Flashback Version Query，能够把时间1、时间2的操作给记录下来，并详细的查询出对表进行的任何操作。

SQL>select versions_starttime,versions_endtime, versions_xid,versions_operation,id

from test versions

between timestamp minvalue and maxvalue

order by versions_starttime;

　　在上述查询中，列 versions_starttime、versions_endtime、versions_xid、versions_operation是伪列，还有一些伪列，如versions_startscn和versions_endscn显示了该时刻的系统更改号。列versions_xid显示了更改该行的事务标识符。

 

　　当然，除了分析以上所有的变更之外，可以根据需要指定时间段，如显示在2005-05-07时间在15:30到16:30之间test表的所有变更。

SQL>select id from test

versions between timestamp to_date(’2005-05-07 15:30:00’,’yyyy-mm-dd hh24:mi:ss’) and to_date(’2005-05-07 16:30:00’,’yyyy-mm-dd hh24:mi:ss’)

　　5、Flashback Transaction Query

　　Oracle Flashback Transaction Query特性确保检查数据库的任何改变在一个事务级别，可以利用此功能进行诊断问题、性能分析和审计事务。它其实是Flashback Version Query查询的一个扩充，Flashback Version Query说明了可以审计一段时间内表的所有改变，但是也仅仅是能发现问题，对于错误的事务，没有好的处理办法。而Flashback Transaction Query提供了从FLASHBACK_TRANSACTION_QUERY视图中获得事务的历史以及Undo_sql（回滚事务对应的sql语句），也就是说审计一个事务到底做了什么，甚至可以回滚一个已经提交的事务。

　　例：Flashback Transaction Query的操作实例。

　　（1）在test表中删除记录，获得事务的标识XID，然后提交。

SQL>delete from test where id=2;

SQL>select xid from v$transaction;

XID

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

04001200AE010000

SQL>commit;

　　在测试中方便起见，在事务没有提交的时候，获得事务的XID为04001F0035000000。实际情况下，不可能去跟踪每个事务，想要获得已提交事务的XID，就必须通过上面的Flashback Version Query。

　　（2）进行Flashback Transaction Query

SQL>select * from FLASHBACK_TRANSACTION_QUERY

where xid=’04001F0035000000’;

UNDO_SQL

insert into "FLASHTEST"."TEST"("ID") values (’2’);

　　注意：这个删除语句对应的是1个Insert语句，如果想回滚这个事务，执行这个Insert语句即可。

　　可以看到，Flashback Transaction Query主要用于审计一个事务，并可以回滚一个已经提交的事务。如果确定出错的事务是最后一个事务，我们利用Flashback Table或者Flashback Query就可以解决问题。但是，如果执行了一个错误的事务之后，又执行了一系列正确的事务，那么上面的方法就无能为力，利用Flashback Transaction Query可以查看或回滚这个错误的事务。

　　　通过上面的描述，可以看出闪回功能使用户恢复偶然的错误删除更加容易，增强了系统的可用性与读一致性。

Flashback database闪回数据库可以迅速的时数据库回到误操作或人为错误的前一个时间点，如实际中的“撤消”操作，将可以不利用备份就快速的实现时间点的恢复（有后悔药可以吃了 ）。实际上，Oracle为了实现这一个功能，创建了另外一组日志，就是Flashback Logs（前滚日志），记录数据库的前滚操作。如果希望能闪回数据库，需要设置如下参数：

DB_RECOVER_FILE_DEST

DB_RECOVER_FILE_DEST_SIZE

这两个参数来确定Flashback日志的存放地点与该恢复区的大小。在创建数据库的时候，Oracle将自动创建恢复区（需要注意，该恢复区可不仅仅是为了flashback log，还可以用来归档，备份与恢复），但是默认是关闭

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

转载于:http://blog.itpub.net/11364208/viewspace-344562/