RMAN增量備份方案增量備份的離線恢復恢復預覽從resetlogs中恢復文件壓縮等被重新設計後變得更加強大了
大多數人都贊同RMAN就是Oracle事實上的數據庫備份工具盡管早期版本的RMAN已經很強大但是人們對它的期待還是有很多很多DBA對於一些很希望有但實際上沒有的特性很煩惱很幸運在g中解決了很多問題並且增加了很多受期待的特性下面就一起看一下
增量備份
RMAN有一項增量備份的功能但實際上你是否經常用它呢？或許偶爾或許從來沒有
這項功能使RMAN備份上一次同級別或者更低級別的增量備份以後發生變化的數據塊例如在第一天執行了一次全備份（level_）在第二三天執行了兩次增量備份（level_）後面兩次備份僅僅備份在第一天和第二天之間變化的數據塊第二天和第三天之間變化的數據塊而不是備份整個數據這種策略降低了備份數據大小只需要較少的空間並且使備份窗口變得更小降低了網絡傳輸數量使用增量備份的最重要的因素為了和數據倉庫環境相關聯因為在數據倉庫中很多操作都是在NOLOGGING模式下進行的並且數據的變化並沒有記錄在歸檔日志文件中因此沒有可用來恢復數據的媒質了由於如今數據倉庫非常盤大所以根本不會考慮使用全備份同時也不可行因而采用增量備份是一個可選的方法
但為什麼那麼多DBA很少采用增量備份呢？一個原因就是在Oracle i和更低版本中RMAN會掃描所有數據塊以定位哪些塊需要被備份這一操作給系統造成了很大的壓力因此增量備份不具備操作性
Oracle G的RMAN對增量備份的方式進行了改進它利用一個和文件系統中日志文件類似的文件來跟蹤從上次備份以來發生變化的數據塊RMAN需要讀這個文件決定哪些塊需要備份
你可以通過執行以下命令來激活這種跟蹤機制
SQL> alter database enable block change tracking using file /rman_bkups/changelog;
可以通過以下查詢語句確定當前跟蹤機制是否被激活
SQL> select filename status from v$block_change_tracking;
閃動恢復區域
在i中的閃回功能依賴於回歸表空間閃回到一個早期狀態這樣就限制它閃回到很早的的狀態通過創建閃回日志閃動恢復提供了一個新的解決方法閃回日志和重做日志類似使數據庫恢復到一個早期狀態總之你可以通過以下SQL語句為數據庫創建一個閃動恢復區域指定它的大小並將數據庫設置為閃動恢復模式
SQL> alter system set db_recovery_file_dest = /ora_flash_area;
SQL> alter system set db_recovery_file_dest_size = g;
SQL> alter system set db_flashback_retention_target = ;
SQL> alter database flashback on;
為了使閃回功能激活數據庫必須在歸檔日志模式上述操作會在目錄/ora_flash_area下創建oracle管理文件（Oracle Managed Files OMF）總的大小使GB數據庫的變化都會記錄在這些文件中可以使數據庫迅速恢復到以前的某一點
默認情況下RMAN也會使用/ora_flash_area目錄來存儲備份文件因此RMAN的備份全市存儲在磁盤上而不是磁帶上這樣的話你就可以設定備份數據保留多少天時間到了後如果需要更多空間時這些文件會被自動刪除
然而閃動恢復區域可以不需要一個文件系統或目錄它可以是一個自動存儲管理（Automatic Storage Management ASM）磁盤組在這種情況下閃動恢復區域可以用以下語句指定
SQL> alter system set db_recovery_file_dest = +dskgrp;
通過ASM和RMAN的結合使用你可以通過使用哪些如Serial ATA和SCSI盤等廉價的磁盤來構建可擴展的容錯性強的存儲系統這種方式不能是備份過程更快而可以使用比磁帶方式更便宜的磁盤來完成同樣的事情
另外一個好處就是避免了用戶錯誤永偉ASM文件不是實際的文件系統他們被DBA和系統管理員損壞的幾率更小
增量合並
假如你有以下的備份計劃星期天做level 的完全備份標識為level_星期一做level 的增量備份標識為level__mon星期四做level 的增量備份標識為level__tue如果數據庫在星期六被損壞了在G之前你不得不恢復level_然後再將所有個增量備份實施上去這樣會消耗很長一段時間這也是很多dba避免使用增量備份的原因之一
Oracle g的RMAN從根本上改變了這種方式現在的增量備份命令如以下這個樣子
RMAN> backup incremental level_ for recover of copy with tag level_ database;
這樣RMAN再做增量備份level_備份時會和標識為level_的完全備份合並經過這樣的備份level_變成了那天的完全備份了
因此在周四標識為level_的備份實際與level_的增量備份合並成了在周四做的完全備份如果在周六數據庫損壞了你只需要將level_的備份加上一些歸檔日志共同恢復就可以了而不需要將增量備份也恢復這種方式大大減少了恢復時間使備份加速並且避免了重新做一個增量備份
壓縮文件
在基於磁盤備份的閃動恢復區域功能中你還有一個很大的限制磁盤容量特別使當通過網絡實現時——實際也經常是這麼用的——強烈建議創建一個盡可能小的備份在G的RMAN中你可以在備份命令中插入壓縮文件的命令
RMAN> backup as compressed backupset incremental level database;
請注意這使用了COMPRESS子句它壓縮的備份文件有一個很重要的特點當恢復時RMAN可以無需解壓文件直接讀取它為了確認是否壓縮可以在輸出信息中檢測是否有以下內容
channel ORA_DISK_: starting compressed incremental level datafile backupset
你還可以通過在RMAN中list output確認備份是否被壓縮
RMAN> list output;
BS Key Type LV Size Device Type Elapsed Time Completion Time
Incr M DISK :: FEB
BP Key: Status: AVAILABLE Compressed: YES Tag:
TAGT
Piece Name:
/ora_flash_area/SMILEY/backupset/__/o_mf_ncsn_TAGT_wmlr_bkp
Controlfile Included: Ckp SCN: Ckp time: FEB
SPFILE Included: Modification time: FEB
就如所有的壓縮動作一樣這一方法會增大CPU的壓力但這也使你可以保留更多的備份在磁盤上以備恢復另外你還可以用RMAN來備份物理備份數據庫以用於恢復主數據庫這一方法可以將備份資源從其他主機上卸載下來
恢復預覽
通過提供了能預覽恢復操作功能Oracle g變得很先進了
RMAN> restore database preview;
… …
你還可以預覽特定的恢復操作如
RMAN>restore tablespace users preview;
… …
預覽功能使你能通過定期的檢查來確認恢復時要做什麼樣的准備
Resetlogs和恢復
假如你丟失了當前的在線重做日志文件又不得不做一次不完全的數據庫恢復最大的問題時resetlogs當不完全恢復後你必須使用resetlogs子句來打開數據它會設置日志線程的序列號為刪除RMAN中早期的備份使恢復操作更容易在Oracle i和更低版本中如果你需要將數據庫從resetlogs中恢復到一個早期狀態你不得不把它恢復成一個不同的樣子在Oracle G中你就不需要這樣做了由於控制文件增加了一些結構RMAN可以在一次resetlogs操作之前或之後隨時利用所有的備份來恢復數據庫做備份使沒有必要關閉數據庫了這一新功能意味著在一次resetlogs操作以後數據庫可以迅速的被用戶打開
From:http://tw.wingwit.com/Article/program/Oracle/201311/16955.html
