在物理備庫上部署閃回資料庫

閃回資料庫特性概述
閃回資料庫技術（flashback database）是從oracle 10g開始提供的一個新特性。其主要功能可以是
將整個資料庫回退到過去的一個時間點，即實現整庫的按時間點恢復功能（database point-in-time recovery,DBPITR）。
閃回資料庫技術通常用於將資料從誤操作或者邏輯損壞中恢復。比如某天11點20有人錯誤的truncate了兩張，10分鐘後
該誤操作被發現，此時一種恢復手段就是利用閃回資料庫將整庫回退到11點20之前，再開啟資料庫匯出相應的資料。
在沒有閃回資料庫技術前，要實現DBPITR，必須藉助媒體介質恢復（media recover）的方式，即依次執行：
1.restore 資料檔案（可能只需要恢復丟失資料所涉及到的部分表空間）
2.restore 歸檔日誌（視情況可能需要）
3.recover資料檔案
相比之下，閃回資料庫技術要快速的多，簡單的多。

在物理備庫上啟用閃回資料庫
為了啟用閃回資料庫特性，DBA必須配置快速恢復區fra,因為oracle將不斷把對資料庫的修改以資料塊為單位寫入
到存放在FRA中的閃回日誌中，這樣會增大系統的物理IO開銷，對於很多磁碟IO已經是最主要效能瓶頸的生產庫而言
啟用閃回會引起DBA的顧慮。
經過實際的配置和測試確認，閃回資料庫這一特性可以僅在物理備庫physical standby database 上開啟，這樣既
不會對生產庫（主庫）的效能產生影響，又可以更充分的利用物理備庫。我們額可以讓物理備庫處於實時應用日誌
（而不是色湖之日誌傳輸和應用的延遲）的狀態下，讓資料差異與主庫維持在一個很短的時間範圍內，以更好的提供
對只讀查詢業務的支援（即11g active data guard）,同時還可以在需要的情況下閃回到一個早期的時間點，以挽救
誤操作丟失的資料。
 在將物理備庫閃回之後，需要以只讀方式開啟，這樣在將需要的資料抽取完畢後，還可以繼續啟動MRP程式並利用
 歸檔日誌檔案追上主庫，DBA不需要重建物理備庫，這樣也大大減輕了DBA的工作量。
 本文將描述在物理備庫中啟用閃回資料庫特性所需要注意的各項配置，主要內容包括：
 1.配置快速恢復區。
 2.啟用閃回資料庫
 3.配置guaranteed restore point
 4.配置歸檔日誌清除策略
 5.測試閃回資料庫
 
 配置快速恢復區
 啟用了閃回資料庫之後，oracle將修改的資料塊的映像不斷的寫入到一種叫“閃回資料庫日誌”的檔案中，藉助於這種
 檔案，oracle才能夠執行資料庫的回退。
 閃回日誌必須儲存與快速恢復區（fast recovery area）中，因此在啟動閃回資料庫功能之前，必須首先設定好快速
 恢復區。
 作為物理備庫，FRA中還需要存放歸檔日誌檔案，並且儲存一定的時間，因為物理備庫在閃回並完成丟失資料的抽取
 後，還需要藉助較早時間點的歸檔檔案進行日誌應用（既MRP）。
 為此DBA需要規劃儲存分配並設定一下3個引數：
 1.log_archive_dest_1 'LOCATION=USE_DB_RECOVERY_FILE_DEST'
 2.db_recovery_file_dest_size 存放閃回日誌和歸檔日誌檔案的目標容量
 3.db_recovery_file_dest 存放閃回日誌和歸檔日誌的目的，可以是ASM或者檔案系統
 啟用閃回資料庫
 開啟閃回資料庫功能的操作非常簡單，首先需要配置好引數
 1.db_flashback_retention_target 閃回視窗的目標時間長度，單位為分鐘，預設為1440既1天。
 最後一步就是將資料庫啟動到mount狀態下，並執行
 startup mount;
 alter database flashback on;
 這樣閃回資料庫
 DBA可以透過這個查詢閃回資料庫特性是否已經開啟。
 select flashback_on from v$database;
 
 配置guaranteed restore point
 oracle可以自動實現對閃回日誌檔案的空間管理，既根據所設定的閃回視窗,FRA區域剩餘的空間狀況以及
 guaranteed restore point,刪除不再需要的閃回日誌，從而避免沾滿空間。
 需要注意的是：閃回視窗的設定值僅僅是一個目標值，oracle將根據實際情況進行調整，系統能夠閃回的最早
 時間點可能比設定的視窗還早，也可能達不到所設定的視窗。
 為了確保能夠閃回到某一段時間之前，必須建立所謂的 guaranteed restore point。比如dba想要在任何
 時刻都可以將資料庫閃回到6個小時前，就必須在6個小時前建立好GRP，這樣oracle不會自動刪除這段時間
 的閃回日誌。過了6個小時之後，DBA必須手動刪除掉這個GRP，從而允許oracle刪除不再需要的閃回日誌並
 釋放出fra的空間。
 假定dba根據實際的業務要求，為保證能夠將資料庫閃回到最多6個小時之前，可以採用如下的配置策略：
 1.建立與刪除GRP的策略：每天的0，3，6，9，12，15，18，21點執行一個定時任務，用來建立一個GRP，
 並刪除6個小時之前的GRP.
 在這種方式下，在任何給定的時間點，系統中都會存在一個6小時前的grp(最多時該GRP可以是9小時之前)
 設定db_flashback_retention_target>=360.
 
  配置歸檔日誌清楚策略
  主要採取如下的清除策略
  總體策略 將歸檔存放於FRA中，這樣歸檔檔案和閃回日誌都屬於oracle managed file,oracle可以根據
  FRA的剩餘空間情況自動清除。
  對於歸檔日誌檔案，採用oracle自動清除與人工清除相結合的方法，以最大限度保證閃回日誌的空間。
  自動刪除策略
  為使oracle可以自動刪除歸檔日誌，配置如下的歸檔刪除策略
  configure archivelog deletion policy to applied on standby;
  人工刪除策略
  同時配置定時任務，以刪除9個小時之前的歸檔日誌。
  測試閃回資料庫
  在以上配置完成後，還需要對系統進行測試以驗證可以實現設定的目標。
  下面為一個簡單測試的主要步驟。
  測試步驟
  1.在15:50左右查詢v$flashback_database_log 檢視，確定可以回退到的最早時間點，在沒有配置
  Guaranteed restore point的情況下，可以回退到11個小時之前。
  select * from v$flashback_database_log;
  2.關閉備庫的MRP，將資料庫重新啟動到mount狀態下。
  3.使用rman執行flashback database 命令
  rman target /
  flashback database to time "to_date('2015-10-30 05:00','yyyy-mm-dd hh24:mi')";
  4.flashback database命令執行完成後，資料庫能夠以只讀方式成功開啟。
  5.執行一些查詢的sql語句作為測試。
  6.啟動備庫的redo apply，此時資料庫將開始追日誌，最終與主庫資料庫的log變為零。
  
  測試結果
  透過本次測試，確認flashback database 命令可以成功執行完成，資料庫能夠以只讀方式開啟。
  隨後資料庫可以繼續應用redo，不需要重建物理備庫。