之前写了一篇文章分享了使用flashback database的特性来在测试环境中避免重复导入大批量的数据,造成时间和存储空间的浪费。 http://www.linuxidc.com/Linux/2015-05/116949.htm 今天碰到的这个问题更有针对性和普遍性,在很多时候都需要一套独立的环境来作为客户的培训和演示需要,环境中的数据一旦配置完成,一般是很少需要改动的。如果培训完成后,第二天如果还有培训或者演示,想得到原来的初始化数据就很困难了。 这个时候我们可以尝试使用flashback database来实现。 在之前的例子中分享了根据时间点或者scn可以达到闪回数据库的目的,其实还有一种方式比较普遍通用,就是使用restore point来做闪回数据库的操作。 假设环境初始化完成之后,我们可以直接设置一个restore point,在后期就不用过分关注时间点或者scn来做闪回操作了。 create restore point original_state_BASE guarantee flashback database;设置了这个restore point之后,我们可以使用下面的脚本来查看设置的这个恢复点。 col NAME for a20 col TIME for a35 set lines 200 col STORAGE_SIZE for a50 SELECT NAME, SCN, TIME, DATABASE_INCARNATION# DI,GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE/1024/1024/1024 FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE="YES"; NAME SCN TIME DI GUA STORAGE_SIZE/1024/1024/1024 -------------------- ---------- ----------------------------------- ---------- --- --------------------------- ORIGINAL_STATE_BASE 4465165 17-APR-15 10.48.01.000000000 AM 1 YES 0 ORIGINAL_STATE 4465180 17-APR-15 10.48.10.000000000 AM 1 YES .68359375 设置了之后,如果后面需要闪回恢复就很容易了。 参考脚本如下,可以很快达到预期的目的。 set echo on feed on set time on timing on -spoo logs/restore_flashback.log select name from v$database; SELECT current_scn FROM v$database; col NAME for a20 col TIME for a35 set lines 100 SELECT NAME, SCN, TIME, DATABASE_INCARNATION# DI,GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE="YES"; shutdown immediate; startup mount; flashback database to restore point ORIGINAL_STATE; alter database open read only; shutdown immediate; startup mount; alter database open resetlogs; spoo off当然了这个回退的原理就是flashback database,但是在特定的使用场景中就赋予了更多的实际意义。 在这个基础上如果根据业务需要,每周的某几天需要做这个回退操作,就可以设置为crontab的方式来自动运行,就不用大半夜,大清早再去做这些回退了。本文永久更新链接地址