之前写了一篇文章分享了使用flashback database的特性来在测试环境中避免重复导入大批量的数据，造成时间和存储空间的浪费。
今天碰到的这个问题更有针对性和普遍性，在很多时候都需要一套独立的环境来作为客户的培训和演示需要，环境中的数据一旦配置完成，一般是很少需要改动的。如果培训完成后，第二天如果还有培训或者演示，想得到原来的初始化数据就很困难了。
这个时候我们可以尝试使用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的方式来自动运行，就不用大半夜，大清早再去做这些回退了。