国庆期间有一个例行维护的任务，需要在大早上7点起来，先根据业务指定的SQL查出指定数据，然后运行一个存储过程来更新数据。
查出来的这部分数据需要作为后期的数据稽核所用，涉及到审计，所以优先级还是比较高的。
因为这样的查询有几个，所以为了统一数据格式，先加了rownum看看数据的基本情况。
SQL类似于下面的形式：
select cn 账号,present_point 剩余积分点 , last_date 积分最后更新时间 from test.user_present_point_sp where present_point > 0 and last_date < to_date('2016-10-07','yyyy-MM-dd') and rownum<10;
操作的过程很快就完成了。因为在内网环境，而且又是使用VPN,这部分数据要拷贝出来还是有一些难度，就和同事商量能不能上班了之后再提供，同事也很爽快，就答应了。
上班的时候，离这个操作的时间已经过去了近3天。
当我把数据提供给同事的时候，同事发现有一个查询的数据出入太大，完全对不上。我查看当时操作的日志发现，这下坏了，语句执行错了。
应该执行的语句是：
select cn 账号,present_point 剩余积分点 , last_date 积分最后更新时间 from test.user_present_point_sp where present_point > 0 and last_date < to_date('2016-10-07','yyyy-MM-dd')；
而我当时格式化的时候竟然给忘了去掉rownum<10 ,那个查询只返回了9条数据。想想这已经过去了好几天，怎么能够保证数据的准确性呢。
带着侥幸心理，尝试通过闪回查询来完成,但是发现这次确实不走运，回滚段还是不满足要求，毕竟时间已经过去了好几天了。
select cn 账号,present_point 剩余积分点 , last_date 积分最后更新时间 from test.user_present_point_sp as of timestamp to_timestamp('2016-10-06 08:00:00','yyyy-mm-dd hh24:mi:ss') where present_point > 0 and last_date < to_date('2016-10-07','yyyy-MM-dd')
*
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 22 with name
"_SYSSMU22_163011606$" too small
这个时候问题就摆在了我的面前，这个问题该怎么解决。首先不能作假，其次这部分内容是要提供的，完全能没有办法通过日志 或者其它的方式来间接得到了。
这个时候我想到了我之前的一个完美的决定。那就是一主两备，在异机备库开了闪回数据库的特性。保留的时间是4天，这下我是这个问题的真正受益者了。
来看看在备库做真实的闪回数据库操作是否可行，这次艰巨的任务就靠它了。
首先确认备库的状态：
SQL> select flashback_on,database_role,open_mode from v$database;
FLASHBACK_ON DATABASE_ROLE OPEN_MODE
------------------ ---------------- --------------------
YES PHYSICAL STANDBY READ ONLY WITH APPLY
确认了时间点，就准备停库，停库前还是需要确认是否有其它的业务连接。
SQL> select username,count(*)from v$session group by username;
USERNAME COUNT(*)
------------------------------ ----------
50
PUBLIC 5
SYS 1
启库到mount阶段，闪回到具体的时间点。
flashback database to timestamp to_timestamp('2016-10-06 07:20:00','yyyy-mm-dd hh24:mi:ss');
这个闪回的过程因为涉及到的闪回日志还是蛮多的，所以持续时间就略微长一些。大概有15分钟的样子。
Sat Oct 08 11:14:59 2016
flashback database to timestamp to_timestamp('2016-10-06 07:20:00','yyyy-mm-dd hh24:mi:ss')
Flashback Restore Start
Sat Oct 08 11:27:03 2016
Flashback Restore Complete
Flashback Media Recovery Start
started logmerger process
Parallel Media Recovery started with 24 slaves
Flashback Media Recovery Log /U01/app/oracle/fast_recovery_area/SGCDB2/archivelog/2016_10_06/o1_mf_1_3696_czc0wj0f_.arc
Flashback Media Recovery Log /U01/app/oracle/fast_recovery_area/SGCDB2/archivelog/2016_10_06/o1_mf_1_3697_czc540wp_.arc
Sat Oct 08 11:27:15 2016
Incomplete Recovery applied until change 229374582017 time 10/06/2016 07:20:01
Sat Oct 08 11:27:15 2016
Flashback Media Recovery Complete
Completed: flashback database to timestamp to_timestamp('2016-10-06 07:20:00','yyyy-mm-dd hh24:mi:ss')
Sat Oct 08 11:29:34 2016
再次查询，数据就是当时的状态了，就和一个完整的快照一样，如果对闪回时间有疑问，还可以再次闪回，直到满足要求，经过比对，发现数据准确无误。
重启数据库，开启日志应用，备库又开始接受应用归档了。整个过程也是有惊无险，我也在这个过程中对闪回数据库有了更深入的理解。对此我有几点感触，一个就是如果异机备库的空间较大，日志量不是非常大，可以考虑将闪回的时间设置长一些。对于很多操作来说，还是需要尽可能保留一些关键的日志，没准哪天那些看似不重要的时间戳就非常重要了。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2126025/，如需转载，请注明出处，否则将追究法律责任。