巧用flashback database实现灵活的数据切换

今天是DTCC第二天了，抽空去听了下，因为手头有一些活，听到一半只能赶回公司继续工作。
客户今天有一个需求，因为开发现在在生产环境中遇到了一些困难，需要在测试生产环境中复现问题，这样就需要从生产环境抽取出一些数据，可能数据量相对比较小，有个1G左右。需要把这些数据加载到测试生产环境中，
还是来张图更加清晰。我们需要把图中右边部分的生产环境中抽取部分数据导入到测试生产环境中，这里所说的测试生产环境是按照生产环境的结构来复制的。测试环境已经有一些测试数据，很可能和生产环境中的数据冲突。
就如同图中下面的部分列出的细节一样，很可能会存在数据冲突导致数据加载出现问题。


按照一般的情况下，我们是建议对测试生产环境做一个备份，采用expdp即可，然后清空对应schema下的数据，然后倒入需要重现问题的数据。问题复现之后，可以使用备份把数据恢复回来。
但是这种固有的思想还是存在一定的问题。
客户反馈的情况如下，说对应的schema下的数据量是相当大的，差不多2T多，如果做备份也是需要不少的空间，导出导入都是相当消耗时间和资源的。
OWNER                          SUM(BYTES)/1024/1024 
------------------------------ -------------------- 
APPO                                  2144666.63
这套环境借用的时间为3天，所以相对来说测试环境的高可用要求就没那么高了。
我们可以尝试采用flashback database来完成这种需求。
使用flashback database会有一些的顾虑和隐患，比如
闪回时间的考虑，如果考虑不周很可能达不到预期的效果。
数据库中默认是不会启用闪回数据库功能的，需要启用，完成数据恢复之后，再禁用，这些过程都是需要停库启库的，对于中间件来说就需要重新启动，需要和开发测试部分做协调，是否同意这种方式。
数据库做闪回操作之后，闪回到了数据清除前的状态，这个时候如果要打开数据库，是需要使用open resetlogs这种方式的，这样的话这个时间点之前的备份就失效了。也需要做确认，确保不会出现业务上意料之外的情况。
很快得到了回复，看来对于这种方式大家也是认可的，毕竟能够免去大量的备份和数据导入导出之苦。操作上也相对比较方便。

我们使用下面的脚本来简单模拟一下。我们创建一个表，然后启用flashback database功能，做truncate操作，然后导入一些新的数据，之后再做闪回数据库操作，闪回到truncate之前的数据情况，最后启用数据库即可。
修改闪回保留的时间，默认是1440分钟，即24小时
SQL> show parameter flashback
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target        integer     1440
我们创建了一个表，大小为2G左右，这样能够简单验证一下闪回日志的增长情况。
SQL> select segment_name,bytes from user_segments where segment_name='AA';
SEGMENT_NAME    BYTES
--------------- ----------
AA              2153775104

SQL> SELECT COUNT(*)FROM AA;
  COUNT(*)
----------
  18340352
  我们开始启用闪回数据库功能。
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area  435224576 bytes
Fixed Size                  1337044 bytes
Variable Size             272632108 bytes
Database Buffers          155189248 bytes
Redo Buffers                6066176 bytes
Database mounted.
SQL> alter database flashback on;
Database altered.
SQL> 
SQL> alter database open;
Database altered.
启用之后，得到一个时间戳，一次来作为我们完成闪回的时间点。
select systimestamp from dual;
接着我们来做一个清理工作。
SQL> truncate table aa;
Table truncated.
我们尝试插入一部分
SQL> insert into aa select*from all_objects;
71642 rows created.
SQL> commit;
Commit complete.
这个数据量相比原本的2G就小了很多。
然后我们尝试使用闪回数据库功能，闪回到删除之前的状态。
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down

SQL> startup mount;
ORACLE instance started.
Total System Global Area  435224576 bytes
Fixed Size                  1337044 bytes
Variable Size             272632108 bytes
Database Buffers          155189248 bytes
Redo Buffers                6066176 bytes
Database mounted.
SQL> Flashback database to timestamp to_timestamp('2015-04-17 17:42:29','yyyy-mm-dd hh24:mi:ss'); 
Flashback complete.
以只读方式打开，做验证，保证闪回没有问题。
SQL> alter database open read only;
Database altered.

SQL> conn n1/n1
Connected.
SQL> select count(*)from aa;
  COUNT(*)
----------
  18340352

数据又回来了。
查看闪回日志的大小，可以看到还是很少的。
total 16040
-rw-r----- 1 ora11g dba 8200192 Apr 17 17:43 o1_mf_bm1oc2qt_.flb
-rw-r----- 1 ora11g dba 8200192 Apr 17 17:45 o1_mf_bm1ofwb7_.flb
[ora11g@oel1 flashback]$ pwd
/u02/ora11g/flash_recovery_area/TEST11G/flashback
[ora11g@oel1 flashback]$    

另外说明一下，对于闪回数据库功能，如果禁用之后，闪回日志会自动清除。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1584057/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-1584057/