Flashback闪回，表级闪回是由undo回滚段作支撑的（表的结构不能改变，不能alter，truncate等ddl操作），而10g的闪回drop的表是由于表空间的虚拟回收站来闪回的，被删除的表只是被重命名而已，在空间足够情况下并没有彻底清除。而10g的数据库级的闪回则是又闪回日志来支撑的！

表级闪回跟undo表空间

SQL> select * from xiaoyu.test03;

ID

----------

44

11

22

33

44

11

22

33

8 rows selected

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

2133219

SQL> insert into xiaoyu.test03 select * from xiaoyu.test03;

8 rows inserted

SQL> commit;

Commit complete

SQL> create undo tablespace undotbspace01 datafile 'd:oracleproduct10.2.0oradataxiaoyuundotbspace01.dbf' size 50M;

Tablespace created

SQL> alter system set undo_tablespace=undotbspace01;

System altered

SQL> drop tablespace undotb including contents and datafiles;

Tablespace dropped

SQL> select * from xiaoyu.test03 as of scn 2133219;

select * from xiaoyu.test03 as of scn 2133219

ORA-01555: 快照过旧: 回退段号 (名称为 "") 过小

可以看出drop原xiaoyu.test03的在insert时期的回滚段所在的回滚表空间，闪回查询时已经无法查找到以前的回滚段出现ora-01555

再看下面的这个例子：

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

2134728

SQL> create undo tablespace undotbs02 datafile 'd:oracleproduct10.2.0oradataxiaoyuundotbs02.dbf' size 50M;

Tablespace created

SQL> insert into xiaoyu.test03 select * from xiaoyu.test03;

32 rows inserted

SQL> commit;

Commit complete

SQL> alter system set undo_tablespace=undotbs02;

System altered

SQL> select count(*) from xiaoyu.test03;

COUNT(*)

----------

64

SQL> select count(*) from xiaoyu.test03 as of scn 2134728;

COUNT(*)

----------

32

SQL> drop tablespace undotbs01 including contents and datafiles;

Tablespace dropped

SQL> select count(*) from xiaoyu.test03 as of scn 2134728;

COUNT(*)

----------

32

看出第二个例子即使删除了原undo的回滚段信息，还是可以进行基于原undo表空间所记录的回滚段的闪回查询，第二个例子在删除原undo表空间前进行了一次闪回查询，个人推断删除表空间前的闪回查询获取了原undo表空间的undo段存储在cache buffer中并结合block构造cr块，所以drop原undo tablespace后闪回查询可以从cache buffer中获取undo block进行查询。

[@more@]