假日期间有一个例行维护的任务，需要在大早上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
　　再次查询，数据是当时的状态了，和一个完整的快照一样，如果对闪回时间有疑问，还可以再次闪回，直到满足要求，经过比对，发现数据准确无误。
　　重启数据库，开启日志应用，备库又开始接受应用归档了。整个过程也是有惊无险，我也在这个过程中对闪回数据库有了更深入的理解。对此我有几点感触，一个是如果异机备库的空间较大，日志量不是非常大，可以考虑将闪回的时间设置长一些。对于很多操作来说，还是需要尽可能保留一些关键的日志，没准哪天那些看似不重要的时间戳非常重要了。