簡介
Flashback數據庫是一種時點(PIT)數據庫恢復的方式這種不完全的恢復策略可以用於恢復由於人為錯誤導致邏輯損壞的數據庫在g中引入之後它的設計目標就是以縮減恢復時間而獲得最大的可用性這篇文章將會探索Flashback數據庫將其與傳統的恢復方法相比較並且演示一下如何配置和執行重現恢復
傳統恢復vs重現數據庫
導致停機的第一個原因就是人為錯誤導致的邏輯損壞這一點已經被廣泛承認關於邏輯損壞的例子從用戶不正確的更新數據和截取表到批處理任務錯誤運行次或者打亂順序比比皆是結果都是相同的——數據庫損壞並且范圍廣闊且難以辨認Oracle通過了兩種策略來將數據庫返回到先前的某個時點上:傳統恢復和重現數據庫
不完全的恢復是數據庫恢復到先前某個狀態的恢復這個過程有兩個步驟:重新存儲數據並向前恢復事務活動到某個你想要的時間傳統恢復和重現數據庫之間的主要區別就是傳統恢復從重新存儲所有的數據文件開始然後才恢復到某個想要的恢復時間而重現數據庫則是在損壞之後通過重新存儲被改變的塊來向後操作從這個角度考慮問題的話讓我們想想在一個TB的數據庫上有MB的數據損壞了傳統的恢復從開始重新存儲TB的應用程序數據開始而重現數據庫則是取回這MB的應用程序數據從而達到損壞前的那個點現在我們分別看看每一種策略
傳統恢復
在Oracle g之前將由於人為錯誤導致問題的數據庫恢復到先前某個時點的唯一選項就是傳統恢復這個策略包括了從備份中取出並重新存儲所有的數據庫數據文件然後再執行向前恢復到某個想要的時間點媒體恢復可以基於服務器(RMAN)也可以基於用戶(操作系統工具)
下圖演示了這個復雜的成本高昂的效率極低的多步驟恢復策略
現在我們看一下用戶執行了SQL並且損壞了數據庫的情況用戶通知了命令中心並且報告了錯誤系統分析師通過與公司不同部門的另外一些人協商管理這次事件恢復通過從備份中重新存儲所有的數據文件並且向前回滾redo日志到希望的時間點而完成恢復時間與數據庫的規模成正比而不是需要恢復的更改的數量這就意味著恢復時間(MTTR)實際上隨著數據庫的規模增長而不斷增加
重現數據庫
在Oracle g中一項新的重現技術特性稱為Flashback Database(重現數據庫)的作為傳統恢復的替代品引入了重現數據庫可以讓你快速恢復整個數據庫到先前的某個時間點而不需要從備份中重新存儲數據庫在數據庫中經常被描述為倒轉按鈕它只是將那些被修改的數據塊恢復到你希望的恢復時間之前然後應用Redo更改記錄來達到希望的恢復時間點這個被修改的數據塊就叫做重現日志
重現數據庫提供了相對於傳統數據庫非常明顯的優勢對於分析型數據庫則沒有這麼明顯的優勢在數據倉庫中塊的操作通常是以不記錄日志的模式執行的在重現數據庫中只要數據庫運行的是文檔日志模式它就可以返回到塊操作之前的某個狀態因為被修改的塊可以通過恢復而撤銷執行的操作
注意:雖然重現數據庫是集成到數據庫中的但是它在Oracle的 Express Edition (XE)中是不可用的
這裡我們看一下用戶執行了SQL並且損壞了數據庫的情況用戶通知了應用程序數據庫管理員他執行了重現數據庫命令數據庫自動恢復到損壞之前的某個點重現數據庫很快使因為它只針對被修改的數據進行操作重現的時間與犯錯誤的數量有關而與數據庫的規模無關
配置重現數據庫
以下的例子演示了命令行配置這也可以用企業管理器來完成
在我們配置重現數據庫之前我們需要照顧以下一些先決條件
Flash Recovery Area
首先我們需要配置一個Flash Recovery Area (FRA)在g中這是個新東西FRA只不過是一個恢復相關文件的磁盤定位對於重現數據庫一個新的後台進程名為Recovery Writer (RVWR)在來自SGA的數據庫重現緩存的映像之前階段性地寫入磁盤作為FRA中的重現日志重現日志是在FRA中由Oracle數據庫自動管理的
重現日志的成本是以空間和性能來衡量的空間是數據庫寫密度的一個因素一個小時運行的以%的數據塊寫入作為重現日志的方式必然會導致磁盤整體空間的%的增長因為塊是以規律的間隔寫入的而不是事務的一部分所以對性能的影響是可以忽略不計的
要配置FRA你需要設置如下的初始化參數:
alter system set db_recovery_file_dest=
C:\oracle\product\\flash_recovery_area scope=both;
alter system set db_recovery_file_dest_size = G scope=both;
存檔
接下來我們需要配置存檔再一次我們需要使用FRA作為我們的文檔日志目的地與傳統恢復類似重現數據庫需要存檔以向前恢復提交的事務在重現日志重新存儲了希望時間之前的時點之後
要最小化配置存檔執行如下的命令按照順序:
SQL> startup mount
ORACLE instance started
Database mounted
SQL> alter database archivelog;
Database altered
SQL> alter database open;
Database altered
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence
Next log sequence to archive
Current log sequence
重現數據庫
配置了這些先決條件之後我們准備好配置重現數據庫了
首先我們需要設置重現保持目標這個初始化參數以分鐘來計算代表我們可以把數據庫返回到多長時間之前它的值決定了FRA中重現日志的數量和時間段下面我們的例子將其設置為小時要理解這個保持時間段並不是保證是非常重要的如果FRA需要空間重現日志將會自動刪除目標保持時間點之前的記錄稍後我們會看到我們保證重現日志的方式在FRA中進行維護有了保持時間段設置重現數據庫可以激活
SQL> startup mount;
ORACLE instance started
Database mounted
SQL> alter system set db_flashback_retention_target = scope=both;
System altered
SQL> alter database flashback on;
Database altered
SQL> alter database open;
Database altered
SQL> select flashback_on from v$database;
FLASHBACK_ON
YES
重現數據庫示例
下面的例子用於演示它想要描述單個表之外的損壞
監控FRA
select namespace_limitspace_used space_reclaimable from v$recovery_file_dest;
NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE
C:\oracle\product\/flash_recovery_area
select * from v$flash_recovery_area_usage;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
CONTROLFILE
ONLINELOG
ARCHIVELOG
BACKUPPIECE
IMAGECOPY
FLASHBACKLOG
在表的映像之前顯示
select c ora_rowscn from my_table;
C ORA_ROWSCN
判斷數據庫的時間點
在gR中你有兩種選擇來捕捉你的數據庫的PIT:時間戳和系統修改號碼(SCN)這個信息是作為重現操作的一部分要求的 捕捉到提交的SCN或者稍後的非常重要而不是數據管理語言操作Oracle提供了一種比較笨拙的方式來捕捉提交的SCN通過userenv(commitscn)函數我們的示例在發生損壞的數據管理語言操作之前捕捉到了這個信息
select current_scn from v$database;
CURRENT_SCN
or
select to_char(sysdateYYYYMMDD:HH:MI:SS)
Recover Time from v$database;
Recover Time
:::
在gR中Oracle通過重新存儲點簡化了這個過程一個重新存儲點就是一個用戶定義的與數據庫PIT相關連的名字可以在時間戳或者SCN中使用可以認為重新存儲點是一個redo歷史的參考標記重新存儲點保留在控制文件中直到重新存儲點被刪除或者重現日志被刪除第二個例子保證了重現數據庫對於恢復是可用的
create restore point my_restore_point;
Operation succeeded
或者
創建重新存儲點my_restrore_point來保證重現數據庫;
注意:重新存儲點並不會保證所有的事務都在那個時間點上提交它不應該與DB的關系型數據庫管理系統中的靜默點混淆了
模擬數據庫損壞
模擬數據庫損壞
insert into my_table values ();
row created
commit;
提交完成
判斷數據庫是否由於人為錯誤導致邏輯損壞
select c ora_rowscn from my_table;
C ORA_ROWSCN
注意:在默認情況下Oracle在時鐘級別上檢索SCN當然時鐘當中的所有行都有一樣的SCN激活行級別的SCN檢索可以在CREATE TABLE命令中使用ROWDEPENDENCIES關鍵字
檢驗重現數據庫是可能的
判斷你可以重現的最早的時間
SELECT OLDEST_FLASHBACK_SCN
to_char(OLDEST_FLASHBACK_TIMEYYYYMMDD:HH:MI:SS)
OLDEST_FLASHBACK_TIME
FROM V$FLASHBACK_DATABASE_LOG;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TI
:::
判斷你是否有重新存儲點
select name scn time from v$restore_point;
NAME SCN TIME
MY_RESTORE_POINT SEP PM
這裡是一些你感興趣的視圖
重現數據庫
你可以在SQL*Plus 或者 RMAN中執行重現數據庫重現數據庫可以是基於修改和重新存儲點的時間RMAN提供了額外的基於選項的日志順序
使用先前創建的重新存儲點來重現數據庫
SQL> shutdown immediate;
Database closed
Database dismounted
ORACLE instance shut down
SQL> startup mount
ORACLE instance started
Database mounted
SQL> flashback database to restore point my_restore_point;
Flashback complete
在警告日志中檢查重現數據庫消息
Sat Sep ::
flashback database to restore point my_restore_point
Sat Sep ::
Flashback Restore Start
Flashback Restore Complete
Flashback Media Recovery Start
parallel recovery started with processes
Sat Sep ::
Recovery of Online Redo Log: Thread Group Seq Reading mem
Mem# errs :
C:\ORACLE\PRODUCT\\ORADATA\ORCL\REDOLOG
Sat Sep ::
Incomplete Recovery applied until change
Flashback Media Recovery Complete
Completed: flashback database to restore point my_restore_point
驗證你的數據庫恢復到你想要的狀態
如果你不滿意你可以再次重現把數據庫向前恢復直到或者執行了完全恢復:recover database
注意:重現數據庫可以通過RESETLOGS執行
SQL> alter database open read only;
Database altered
SQL> select c ora_rowscn from my_table;
C ORA_ROWSCN
為一般用途打開數據庫
對我們的恢復滿意了之後為了一般用途打開數據庫
SQL> shutdown;
Database closed
Database dismounted
ORACLE instance shut down
SQL> startup mount;
ORACLE instance started
Database mounted
SQL> alter database open resetlogs;
Database altered
結論
重現數據庫將會成為我最喜歡的Oracleg特性之一無論你是否糾正了用戶的錯誤只是看看先前的數據庫狀態或者在衰退測試之後回到測試環境中這個特性都是減少恢復時間的最好策略我們看到這項技術很容易使用比傳統的恢復更快並且最好的是它是免費的!我希望你也會認為重現數據庫是可用性體系結構中的一項主要組件
From:http://tw.wingwit.com/Article/program/Oracle/201311/18586.html
