flashback注意事项整理

Flashback Drop 需要注意的地方：

1). 只能用于非系统表空间和本地管理的表空间

2). 对象的参考约束不会被恢复，指向该对象的外键约束需要重建。

3). 对象能否恢复成功，取决与对象空间是否被覆盖重用。

4). 当删除表时，信赖于该表的物化视图也会同时删除，但是由于物化视图并不会被放入recycle bin，因此当你执行flashback table to before drop 时，也不能恢复依赖其的物化视图，需要dba 手工介入重新创建。

5). 对于Recycle Bin中的对象，只支持查询.

（1）基于undo 的表恢复，需要注意DDL 操作的影响。修改并提交过数据之后，对表做过DDL 操作，包括：drop/modify 列, move 表, drop 分区(如果有的话), truncate table/partition，这些操作会另undo 表空间中的撤销数据失效，对于执行过这些操作的表应用flashback query 会触发ORA-01466 错误。

   另外一些表结构修改语句虽然并不会影响到undo 表空间中的撤销记录，但有可能因表结构修改导致undo 中重做记录无法应用的情况，比如对于增加了约束，而flashback query 查询出的undo 记录已经不符合新建的约束条件，这个时候直接恢复显然不可能成功，你要么暂时disable 约束，要么通过适当逻辑，对要恢复的数据进行处理之后，再执行恢复。

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

  Flashback Database 功能非常类似与RMAN的不完全恢复， 它可以把整个数据库回退到过去的某个时点的状态， 这个功能依赖于Flashback log 日志。 比RMAN更快速和高效。 因此Flashback Database 可以看作是不完全恢复的替代技术。 但它也有某些限制：

（1）Flashback Database 不能解决Media Failure， 这种错误RMAN恢复仍是唯一选择。

（2）如果删除了数据文件或者利用Shrink技术缩小数据文件大小，这时不能用Flashback Database技术回退到改变之前的状态，这时候就必须先利用RMAN把删除之前或者缩小之前的文件备份restore 出来， 然后利用Flashback Database 执行剩下的Flashback Datbase。

（3）如果控制文件是从备份中恢复出来的，或者是重建的控制文件，也不能使用Flashback Database。

（4）使用Flashback Database锁能恢复到的最早的SCN， 取决与Flashback Log中记录的最早SCN。

删除Recycle Bin占用的空间：

  1). Purge tablespace tablespace_name : 用于清空表空间的Recycle Bin

  2). Purge tablespace tablespace_name user user_name: 清空指定表空间的Recycle Bin中指定用户的对象

  3). Purge recyclebin: 删除当前用户的Recycle Bin中的对象

  4). Purge dba_recyclebin: 删除所有用户的Recycle Bin中的对象，该命令要sysdba权限

  5). Drop table table_name purge:  删除对象并且不放在Recycle Bin中，即永久的删除，不能用Flashback恢复。

  6). Purge index recycle_bin_object_name： 当想释放Recycle bin的空间，又想能恢复表时，可以通过释放该对象的index所占用的空间来缓解空间压力。 因为索引是可以重建的。