flashback恢复表数据被错误update

在之前的项目实施过程中，一个同事跟我说了一个现象，说一不小心把表的某一列所有数据给update，并且已经提交，搞得他焦头烂泥的，最后他的解决方案着实把我吓到拉，他说幸运的是还可以从其他表中恢复，因为这一列的数据跟另外一张表的数据是一样的。最后，我直接跟他说，我只需要一条语句就可以解决。

下面通过示例来看一下：

先创建一张临时表：

 

查看系统时间，当然这个时间可以是大概时间，在实际过程中，当然在你update之前的数据基本上是不变的。

查看当前表中含有多少条sys用户数据

对表数据做update，并且提交，再次查看sys用户下的数据。

这个时候发现更新错误，想把数据恢复回去从新update，这个时候flashback来帮你解决

 最后发现数据回来啦，当然这个功能基于undo在恢复的范围之内。另外，如果你的undo表空间足够大，或者说你的数据库比较空闲的话，这数据就会一直保留在undo表空间中，即使已经提交。下面是一段关于undo_retention的说明和为什么会出现经典的 ORA-01555: snapshot too old .

UNDO_RETENTION specifies (in seconds) the low threshold value of undo retention. For AUTOEXTEND undo tablespaces, the system retains undo for at least the time specified in this parameter, and automatically tunes the undo retention period to satisfy the undo requirements of the queries. For fixed- size undo tablespaces, the system automatically tunes for the maximum possible undo retention period, based on undo tablespace size and usage history, and ignores UNDO_RETENTION unless retention guarantee is enabled.

The setting of this parameter should account for any flashback requirements of the system. Automatic tuning of undo retention is not supported for LOBs. The RETENTION value for LOB columns is set to the value of the UNDO_RETENTION parameter.

The UNDO_RETENTION parameter can only be honored if the current undo tablespace has enough space. If an active transaction requires undo space and the undo tablespace does not have available space, then the system starts reusing unexpired undo space. This action can potentially cause some queries to fail with a "snapshot too old" message。