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