Flashback Transaction Query

Flashback Transaction Query也是使用UNDO信息来实现。利用这个功能可以查看某个事务执行的所有变化，它需要访问flashback_transaction_query 视图，这个视图的XID列代表事务ID，利用这个ID可以区分特定事务发生的所有数据变化。

示例：

SQL> insert into B values(3);

已创建 1 行。

SQL> commit;

提交完成。

SQL> select * from B;

        ID

       ----------

         1

         2

         3

查看视图，每个事务都对应相同的XID

SQL>Select xid,operation,commit_scn,undo_sql from flashback_transaction_query where xid in (

Select versions_xid from B versions between scn minvalue and maxvalue);

或者

SQL>select xid,commit_scn,commit_timestamp,operation,undo_sql

from flashback_transaction_query q where q.xid in(select versions_xid from B versions between scn 413946 and 413959);

XID              OPERATION                        COMMIT_SCN

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

UNDO_SQL

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

03001C006A020000 DELETE                              1100723

insert into "SYS"."B"("ID") values ('4');

03001C006A020000 DELETE                              1100723

insert into "SYS"."B"("ID") values ('3');

03001C006A020000 DELETE                              1100723

insert into "SYS"."B"("ID") values ('2');

Flashback Table

注意SYS用户不支持闪回，这点前面已经说明过。

Flashback Table也是使用UNDO tablespace的内容来实现对数据的回退。该命令相对简单，输入：flashback table table_name to scn(to timestamp) 即可。

注意：如果想要对表进行flashback，必须允许表的row movement.

Alter table table_name row movement;

要查看某表是否启用row movement，可以到user_tables 中查询(或all_tables,dba_tables)，

例如：

SQL> select row_movement from user_tables where table_name='C';

ROW_MOVE

--------

ENABLED

要启用或禁止某表row movement，可以通过下列语句：

--启用

JSSWEB> ALTER TABLE table_name ENABLE ROW MOVEMENT;

表已更改。

--禁止

JSSWEB> ALTER TABLE table_name DISABLE ROW MOVEMENT;

表已更改。

举例：

SQL> create table C (id number(2));

表已创建。

SQL> insert into C values(1);

已创建 1 行。

SQL> insert into C values(2);

已创建 1 行。

SQL> commit;

提交完成。

SQL> select * from c;

        ID

----------

         1

         2

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

会话已更改。

SQL> select sysdate from dual;

SYSDATE

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

2009-10-15 21:17:47

SQL> select current_scn from v$database;

CURRENT_SCN

-----------

      1103864

删除数据并恢复

SQL> delete from C;

已删除2行。

SQL> commit;

提交完成。

SQL> alter table c enable row movement;

表已更改。

SQL> flashback table c to scn  1103864;

闪回完成。

或者：

SQL> flashback table c to timestamp to_timestamp('2009-10-15 21:17:47','yyyy-mm-

dd hh24:mi:ss');

SQL> select * from c;

        ID

----------

         1

         2

Flashback table 命令支持同时操作多个表，表名中间以逗号分隔即可，如果你执行一条flashback table命令时同时指定了多个表，要记住单个flashback table 是在同一个事务中，因此这些表的恢复操作要么都成功，要么都失败。

如：

flashback table a,b ,c to scn 1103864;

一些注意事项

1. 基于undo 的表恢复，需要注意DDL 操作的影响

第三个就是修改并提交过数据之后，对表做过DDL 操作，包括：

drop/modify 列, move 表, drop 分区(如果有的话), truncate table/partition，这些操作会另undo 表空间中的撤销数据失效，对于执行过这些操作的表应用flashback query 会触发ORA-01466 错误。另外一些表结构修改语句虽然并不会影响到undo 表空间中的撤销记录，但有可能因表结构修改导致undo 中重做记录无法应用的情况，比如对于增加了约束，而flashback query 查询出的undo 记录已经不符合新建的约束条件，这个时候直接恢复显然不可能成功，你要么暂时disable 约束，要么通过适当逻辑，对要恢复的数据进行处理之后，再执行恢复。

另外，flashback query 对v$tables,x$tables 等动态性能视图无效，不过对于dba_*,all_*,user_*等数据字典是有效的。同时该特性也完全支持访问远端数据库，比如select * from tbl@dblink as of scn 360;的形式。

2. 基于undo 的表恢复，flashback table 实际上做的也是dml 操作(会在被操作的表上加dml 锁)，因此还需要注意triggers 对其的影响，默认情况下，flashback table to scn/timestamp 在执行时会自动disable 掉与其操作表相差的triggers，如果你希望在此期间trigger 能够继续发挥做用，可以在flashback table 后附加

ENABLE TRIGGERS 子句。

补充：

什么是Automatic Undo Management( 自动撤销管理表空间)

提到自动撤销管理表空间，就不得不提手动管理的回滚段。在9i 之前，回滚段的管理和监控是需要dba手工介入的，创建合适的回滚段是件非常耗费dba 精力的事情，你可能需要不断关注oracle 运行状况很长一阵子时间后，通过不断的调整才能基本确认一段时期内回滚段的大小，一旦回滚段创建的不合适，就极有可能引起性能问题甚至错误，比如ora-1555 就是典型的回滚段设置不合适触发的。

9i 之后呢(含9i)，oracle 为了清晰它的整个概念，取消了回滚段这个说法(实际上并未取消回滚段)，而完全以undo 来代替，这也它正好与redo 相对应，一个重做，一个撤销。回滚段可以不再由dba 手工介入，而是完全由它自己在运行时自动分配，这在一定程度上即解放了dba，也确实起到了提高性能的作用，比如采用自动管理表空间就可以最大程序的降低ora-1555发生的机率(注意是降低，不是避免，我们不可能创建一个无限大的回滚段，ora-1555 也并不完全是回滚段造成的，关于ora-1555 的问题这里就不深入讨论了，互联网上已经有太多文章描述和介绍该问题及解决方案)

是否起用自动管理的撤销表空间由二个初始化参数决定：

UNDO_MANAGEMENT：值为AUTO 表示使用了自动撤销管理表空间，MANUAL 则表示手动管理

UNDO_TABLESPACE：当UNDO_MANAGEMENT 值为AUTO 时，该参数用来指定当前的undo 表空间名称。

undo 表空间的大小，直接影响到flashback query 的查询能力，因为多版本查询所依赖的undo 数据都存储在undo 表空间中，该表空间越大，所能够存储的undo 数据自然也越多，如果该表空间可用空间非常小，别说flashback 了，恐怕正常查询都有可能触发ora-1555 吧。

初始化参数UNDO_RETENTION

该参数用来指定undo 记录保存的最长时间，以秒为单位，是个动态参数，完全可以在实例运行时随时修改通常默认是900 秒，也就是15 分钟。

一定要注意，undo_retention 只是指定undo 数据的过期时间，并不是说，undo 中的数据一定会在undo表空间中保存15 分钟，比如说刚一个新事务开始的时候，如果undo 表空间已经被写满，则新事务的数据会自动覆盖已提交事务的数据，而不管这些数据是否已过期，因此呢，这就又关联回了第一点，当你创建

一个自动管理的undo 表空间时，还要注意其空间大小，要尽可能保证undo 表空间有足够的存储空间。

同时还要注意，也并不是说，undo_retention 中指定的时间一过，已经提交事务中的数据就立刻无法访问，它只是失效，只要不被别的事务覆盖，它会仍然存在，并可随时被flashback 特性引用。如果你的undo表空间足够大，而数据库又不是那么繁忙，那么其实undo_retention 参数的值并不会影响到你，哪怕你设置成1，只要没有事务去覆盖undo 数据，它就会持续有效。因此呢，这里还是那句话，要注意undo 表空间的大小，保证其有足够的存储空间。

只有在一种情况下，undo 表空间能够确保undo 中的数据在undo_retention 指定时间过期前一定有效，就是为undo 表空间指定Retention Guarantee，指定之后，oracle 对于undo 表空间中未过期的undo 数据不会覆盖，

例如：

SQL> Alter tablespace undotbs1 retention guarantee;

如果想禁止undo 表空间retention guarantee，

例如：

SQL> Alter tablespace undotbs1 retention noguarantee;

（文章来自网络，如有侵权请来信告知，本站将在第一时间删除。）