使用闪回查询备份数据(r2笔记43天)

时间:2022-05-04
本文章向大家介绍使用闪回查询备份数据(r2笔记43天),主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

今天在生产环境中,开发人员提交了一个脚本,是做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.充分的测试也很重要,保证数据的安全和高可用是很重要的。