Oracle閃回原理測試（三）(r12筆記第16天)

 對於Oracle的閃回，很多朋友也問過問，到底是怎麼玩的？如果自己做過一些閃回資料庫的操作，就會發現這個功能非常強悍。

  Flashback DML的操作其實還蠻容易理解的，但是Flashback DDDL那可就是另外一個level了，我們大概瞭解一下MySQL裡面的閃回就會發現，真要實現無縫的全閃回，確實有很多的細節和場景需要考慮。而Oracle作為一個成熟的商業軟體，是不希望我們瞭解很多底層的細節的，用著好就行，所以如果你想得到一些閃回更細節的東西，這個渠道就非常的窄，我們之前也測試了兩期，做了一些簡單的對比，這一期就做一些基本的突破，對閃回原理做出進一步的解讀。

    這個嘗試來源於今天的一個維護更新，今天早間的時候，會按照季度的業務要求DBA做一個統一的批次查詢，得到一些資料供審計和策劃的同學分析，提前給出一些解決方案，這個事情是大概一週前提的了，而悲劇的是今天到了公司才想起了有這麼一回事。而這個時候資料已經被當日的資料更新了，想要得到早間指定時間段的資料就尤為關鍵，當然我還算是胸有成竹，因為這個備庫我開了閃回。所以我可以很快閃回到指定的近期任意時間點，也算是閃回化解了這樣一次尷尬的境地。

   當然我在處理問題的時候，還不忘看看閃回的原理，記錄日誌，其實主要是我對閃回特性的充分自信，要不手心裡早都冒汗了。 

   首先確認資料庫角色和狀態之後，我關閉資料庫，準備從mount狀態閃回，避免重啟資料庫。

  下面的錯誤值得注意，在close這個操作時，還是需要保證資料庫的日誌應用是終止的，即MRP為停止狀態。

SQL> alter database close;
alter database close
*
ERROR at line 1:
ORA-10457: cannot close standby database due to active media recovery我們選擇快捷的命令方式，直接關閉日誌應用，然後關閉資料庫。

SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database close;
Database altered.這個操作完成之後，掃了一眼redo和控制檔案，已經更新了時間，閃回工作迫在眉睫。我把資料庫閃回到了幾個小時之前的一個時間點。

SQL> flashback database to timestamp to_timestamp('2017-03-27 07:20:00','yyyy-mm-dd hh24:mi:ss');
Flashback complete.這個過程持續時間很短，所有資料檔案的時間戳都更新到了當前的時間點，而其實資料已經閃回到了幾個小時之前。

  當然下面的一段日誌吸引了我。

Mon Mar 27 10:19:24 2017
flashback database to timestamp to_timestamp('2017-03-27 07:20:00','yyyy-mm-dd hh24:mi:ss')
Flashback Restore Start
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/2017_03_27/o1_mf_1_10600_dfjjm98t_.arc
Flashback Media Recovery Log /U01/app/oracle/fast_recovery_area/SGCDB2/archivelog/2017_03_27/o1_mf_1_10601_dfjonfly_.arc
Mon Mar 27 10:19:43 2017
Incomplete Recovery applied until change 234220253426 time 03/27/2017 07:20:01
Mon Mar 27 10:19:43 2017
Flashback Media Recovery Complete
Completed: flashback database to timestamp to_timestamp('2017-03-27 07:20:00','yyyy-mm-dd hh24:mi:ss')上面的幾處紅字需要格外注意，裡面出現了歸檔日誌檔案，這個就需要再提一下。我們可以透過日誌看出，整個閃回的工作其實分為兩大部分，restore和recover，這個和正常恢復資料如出一轍。但是差別也很明顯，因為閃回日誌是記錄的資料變化的逆操作，所以從10:30閃回到7:20,那麼這個過程就是10:30-> 7:20左右。

   注意我提到的這個7:20是左右，當然要偏左一些，偏右證明資料還太新了。Restore的這個過程會應用到閃回日誌。其實在Oracle中存在一個概念叫做Flashback barrier interval,預設是是30分鐘會往閃回日誌裡寫入SCN的標示紀錄。所以10:30->7:20的操作你也可以理解為大體是按照10:30->10:00->9:30->9:00->8:30->8:00->7:30->7:00這樣的過程。

    完成了基本的還原之後，我們要到達指定時間點的狀態，這就需要使用歸檔檔案或者重做日誌了，這裡的重點就是Flashback Recover的過程了。我們可以透過上面的日誌看到，其實應用了兩個日誌檔案，序列號為10600和10601，這個過程該如何更好的驗證呢。可以透過如下的SQL來做一個基本的分析，當然這個語句還不夠嚴謹。主要思路就是根據v$archived_log來確定一個邊界範圍。

set linesize 150 pagesize 100
with maxlogchg as
(select max(first_change#) c1 from v$archived_log where first_change#<=234220253426)     
select name,sequence#,first_change#,next_change# from v$archived_log,maxlogchg where first_change#>=maxlogchg.c1 and first_change#<=234220253426;   整個資料閃回之後，我們就穿越到了之前的一個時間點，可以做我們需要的操作了。

   整個查詢的過程持續時間很短，但是得到的這個資料就尤為重要了。根據業務執行一些查詢指令碼，此處省略查詢的SQL語句。

    完成之後，我們只需要alter database close,然後正常open就會更新到最新的一個時間點的資料狀態。

SQL>alter database close;
SQL>alter database open
SQL> recover managed standby database disconnect from session;
Media recovery complete.
這個過程的日誌其實省略了一些東西，我想也是為了避免給使用者帶來困擾，因為在日誌裡反反覆覆recover,可能會讓使用者有些疑惑，而我們也可以透過另外一個隱含引數（_flashback_verbose_info）來得到更加詳細的日誌資訊。

  預設得到的正常日誌如下：

Mon Mar 27 10:40:06 2017
ALTER DATABASE RECOVER  managed standby database disconnect from session  
Attempt to start background Managed Standby Recovery process (gcdb)
Mon Mar 27 10:40:06 2017
MRP0 started with pid=28, OS id=139822
MRP0: Background Managed Standby Recovery process started (gcdb)
 started logmerger process
Mon Mar 27 10:40:11 2017
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 24 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Delayed for 180 minute(s) (thread 1 sequence 10601)
Completed: ALTER DATABASE RECOVER  managed standby database disconnect from session 透過如上的日誌，你看不到很多潛在的recover操作。而整個過程而言卻又是必須的。

   透過這個過程我們可以大體看出，整個閃回的過程不是孤立，完全依賴於閃回日誌，而同時也是一個Flashback Restore和Flashback Recover的過程。