巧用閃回資料庫來檢視歷史資料

國慶期間有一個例行維護的任務，需要在大早上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
再次查詢，資料就是當時的狀態了，就和一個完整的快照一樣，如果對閃回時間有疑問，還可以再次閃回，直到滿足要求，經過比對，發現資料準確無誤。
重啟資料庫，開啟日誌應用，備庫又開始接受應用歸檔了。整個過程也是有驚無險，我也在這個過程中對閃回資料庫有了更深入的理解。對此我有幾點感觸，一個就是如果異機備庫的空間較大，日誌量不是非常大，可以考慮將閃回的時間設定長一些。對於很多操作來說，還是需要儘可能保留一些關鍵的日誌，沒準哪天那些看似不重要的時間戳就非常重要了。