今天在生产环境中,开发人员提交了一个脚本，是做update操作的，但是update操作的时候过滤条件有些大，本来预计修改的数据只有5000条，结果这个语句运行下来更改了500万条数据。对生产系统来说算是一个数据灾难，赶紧和开发确认了问题发生的时间，结果说是在半夜11点多，刚好在后半夜才开始做数据备份，这样这个变更也同时影响了备份，就算做紧急的数据恢复也是没有任何效果的。目前采用的备份都是全量的按天备份，备份收到影响，恢复还是比较困难的。这个问题就在紧急的讨论中分为了两个步骤，我来尝试恢复昨天备份前的数据，提供的时间戳是23:48:48 ，而且经过确认这个表中的数据变化很小。如果能够恢复出表中的数据在那个时间点之前，就能把问题降低到最低。开发从业务的角度看能不能同时提供一些修复。我查看了undo的空间使用，还是比较充足的，早上已经是10点左右了，所以就是尽快的做数据的恢复，使用闪回查询来做。这个操作也不是百分百好使，毕竟还是依赖一些缓存空间和系统的负载，在反复确认时间后，写了如下的语句。把时间戳提前了3秒。create table tmp_xxxxx as select * from owner_account.xxxxx as of timestamp to_timestamp('20140723234845','yyyymmddHH24miss');