今天在生产环境中,开发人员提交了一个脚本，是做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');
为了保证不会有其他潜在的因素影响，所以保守起见，没启并行，没加hint
然后就是通过脚本来监控表空间的使用率。看着空间消耗开始一点点增加，最终恢复了昨晚的数据。有了这些数据，就算暂时不会用到，心里也踏实了。
后来开发确认，有一个字段a，这个字段在表里存放的数据就是null，结果开发的update语句相当于又修改了一次，经过反复确认，算是虚惊一场，不过也需要总结不少的经验。
1.在脚本提交之前，如果是dml语句，最好能够评估修改的影响范围，
2.如果脚本比较大，有性能方面的潜在因素，需要让dba来把把关，看看能不能做点什么。
3.充分的测试也很重要，保证数据的安全和高可用是很重要的。
这个问题就在紧急的讨论中分为了两个步骤，我来尝试恢复昨天备份前的数据，提供的时间戳是23:48:48 ，而且经过确认这个表中的数据变化很小。如果能够恢复出表中的数据在那个时间点之前，就能把问题降低到最低。
开发从业务的角度看能不能同时提供一些修复。
我查看了undo的空间使用，还是比较充足的，早上已经是10点左右了，所以就是尽快的做数据的恢复，使用闪回查询来做。这个操作也不是百分百好使，毕竟还是依赖一些缓存空间和系统的负载，在反复确认时间后，写了如下的语句。把时间戳提前了3秒。
create table tmp_xxxxx as select * from owner_account.xxxxx as of timestamp to_timestamp('20140723234845','yyyymmddHH24miss');
为了保证不会有其他潜在的因素影响，所以保守起见，没启并行，没加hint
然后就是通过脚本来监控表空间的使用率。看着空间消耗开始一点点增加，最终恢复了昨晚的数据。有了这些数据，就算暂时不会用到，心里也踏实了。
后来开发确认，有一个字段a，这个字段在表里存放的数据就是null，结果开发的update语句相当于又修改了一次，经过反复确认，算是虚惊一场，不过也需要总结不少的经验。
1.在脚本提交之前，如果是dml语句，最好能够评估修改的影响范围，
2.如果脚本比较大，有性能方面的潜在因素，需要让dba来把把关，看看能不能做点什么。
3.充分的测试也很重要，保证数据的安全和高可用是很重要的。
