Oracle 10G 新特性——RMAN

Oracle 10G 新特性——RMAN

作者：fuyuncat

來源：http://www.hellodba.com/

RMAN增量備份方案、增量備份的離線恢複、恢複預覽、從resetlogs中恢複、檔案壓縮等被重新設計後變得更加強大了。

大多數人都贊同RMAN就是Oracle事實上的Database Backup工具。儘管早期版本的RMAN已經很強大，但是人們對它的期待還是有很多。很多DBA對於一些很希望有但實際上沒有的特性很煩惱。很幸運，在10g中解決了很多問題並且增加了很多受期待的特性，下面就一起看一下。

增量備份

RMAN有一項增量備份的功能。但實際上你是否經常用它呢？或許偶爾，或許從來沒有。

這項功能使RMAN備份上一次同層級或者更低層級的增量備份以後發生變化的資料區塊。例如，在第一天執行了一次全備份（level_0），在第二、三天執行了兩次增量備份（level_1）。後面兩次備份僅僅備份在第一天和第二天之間變化的資料區塊、第二天和第三天之間變化的資料區塊，而不是備份整個資料。這種策略降低了備份資料大小，只需要較少的空間，並且使備份視窗變得更小，降低了網路傳輸數量。使用增量備份的最重要的因素為了和資料倉儲環境相關聯。因為在資料倉儲中，很多操作都是在NOLOGGING模式下進行的，並且資料的變化並沒有記錄在歸檔記錄檔中，因此，沒有可用來恢複資料的媒質了。由於如今資料倉儲非常盤大，所以根本不會考慮使用全備份，同時也不可行。因而採用增量備份是一個可選的方法。

但為什麼那麼多DBA很少採用增量備份呢？一個原因就是在Oracle 9i和更低版本中，RMAN會掃描所有資料區塊以定位哪些塊需要被備份。這一操作給系統造成了很大的壓力，因此增量備份不具備操作性。

Oracle 10G的RMAN對增量備份的方式進行了改進。它利用一個和檔案系統中記錄檔類似的檔案，來跟蹤從上次備份以來發生變化的資料區塊。RMAN需要讀這個檔案決定哪些塊需要備份。

你可以通過執行以下命令來啟用這種跟蹤機制：

SQL> alter database enable block change tracking using file '/rman_bkups/change.log';

可以通過以下查詢語句確定當前跟蹤機制是否被啟用：

SQL> select filename, status from v$block_change_tracking;

閃動恢複地區

在9i中的閃回功能依賴於迴歸資料表空間閃回到一個早期狀態，這樣就限制它閃回到很早的的狀態。通過建立閃回日誌，閃動恢複提供了一個新的解決方案。閃回日誌和重做日誌類似，使資料庫恢複到一個早期狀態。總之，你可以通過以下SQL語句為資料庫建立一個閃動恢複地區，指定它的大小，並將資料庫設定為閃動復原模式：

SQL> alter system set db_recovery_file_dest = '/ora_flash_area';

SQL> alter system set db_recovery_file_dest_size = 2g;

SQL> alter system set db_flashback_retention_target = 1440;

SQL> alter database flashback on;

為了使閃回功能啟用，資料庫必須在歸檔記錄模式。上述操作會在目錄/ora_flash_area下建立oracle管理檔案（Oracle Managed Files OMF），總的大小使2GB。資料庫的變化都會記錄在這些檔案中，可以使資料庫迅速恢複到以前的某一點。

預設情況下，RMAN也會使用/ora_flash_area目錄來儲存備份檔案。因此，RMAN的備份全市儲存在磁碟上，而不是磁帶上。這樣的話，你就可以設定備份資料保留多少天，時間到了後，如果需要更多空間時這些檔案會被自動刪除。

然而，閃動恢複地區可以不需要一個檔案系統或目錄，它可以是一個自動儲存管理（Automatic Storage Management ASM）磁碟組。在這種情況下，閃動恢複地區可以用以下語句指定：

SQL> alter system set db_recovery_file_dest = '+dskgrp1';

通過ASM和RMAN的結合使用，你可以通過使用哪些如Serial ATA和SCSI盤等廉價的磁碟來構建可擴充的、容錯性強的儲存系統。這種方式不能是備份過程更快，而可以使用比磁帶方式更便宜的磁碟來完成同樣的事情。

另外一個好處就是避免了使用者錯誤。永偉ASM檔案不是實際的檔案系統，他們被DBA和系統管理員損壞的幾率更小。

增量合并

假如你有以下的備份計劃：星期天做level 0的完全備份，標識為level_0；星期一做level 1的增量備份，標識為level_1_mon；星期四做level 1的增量備份，標識為level_1_tue。如果資料庫在星期六被損壞了，在10G之前你不得不恢複level_0然後再將所有6個增量備份實施上去，這樣會消耗很長一段時間。這也是很多dba避免使用增量備份的原因之一。

Oracle 10g的RMAN從根本上改變了這種方式，現在的增量備份命令如以下這個樣子：

RMAN> backup incremental level_1 for recover of copy with tag level_0 database;

這樣RMAN再做增量備份level_1備份時會和標識為level_0的完全備份合并。經過這樣的備份，level_0變成了那天的完全備份了。

因此，在周四，標識為level_0的備份實際與level_1的增量備份合并，成了在周四做的完全備份。如果在周六資料庫損壞了，你只需要將level_0的備份加上一些歸檔日誌共同恢複就可以了。而不需要將增量備份也恢複。這種方式大大減少了恢復，使備份加速，並且避免了重新做一個增量備份。

壓縮檔

在基於磁碟備份的閃動恢複地區功能中，你還有一個很大的限制：磁碟容量。特別使當通過網路實現時——實際也經常是這麼用的——強烈建議建立一個儘可能小的備份。在10G的RMAN中，你可以在備份命令中插入壓縮檔的命令：

RMAN> backup as compressed backupset incremental level 1 database;

請注意這使用了COMPRESS子句。它壓縮的備份檔案有一個很重要的特點：當恢複時，RMAN可以無需解壓檔案直接讀取它。為了確認是否壓縮，可以在輸出資訊中檢測是否有以下內容：

channel ORA_DISK_1: starting compressed incremental level 1 datafile backupset

你還可以通過在RMAN中list output確認備份是否被壓縮：

RMAN> list output;

 

BS Key Type LV Size       Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ---------------

3       Incr 1 2M         DISK        00:00:00     26-FEB-04

        BP Key: 3   Status: AVAILABLE Compressed: YES Tag:

TAG20040226T100154

        Piece Name:

/ora_flash_area/SMILEY10/backupset/2004_02_26/o1_mf_ncsn1_TAG20040226T100154_03w2m3lr_.bkp

 Controlfile Included: Ckp SCN: 318556       Ckp time: 26-FEB-04

 SPFILE Included: Modification time: 26-FEB-04

就如所有的壓縮動作一樣，這一方法會增大CPU的壓力。但這也使你可以保留更多的備份在磁碟上以備恢複。另外，你還可以用RMAN來備份物理備份資料庫以用於恢複主要資料庫。這一方法可以將備份資源從其他主機上卸載下來。

恢複預覽

通過提供了能預覽恢複操作功能，Oracle 10g變得很先進了：

RMAN> restore database preview;

… …

你還可以預覽特定的恢複操作，如：

RMAN>restore tablespace users preview;

… …

預覽功能使你能通過週期性檢查來確認恢複時要做什麼樣的準備。

Resetlogs和恢複

假如你丟失了當前的線上重做記錄檔又不得不做一次不完全的資料庫恢複。最大的問題時resetlogs。當不完全恢複後，你必須使用resetlogs子句來開啟資料，它會設定日誌線程的序號為1，刪除RMAN中早期的備份，使恢複操作更容易。在Oracle 9i和更低版本中，如果你需要將資料庫從resetlogs中恢複到一個早期狀態，你不得不把它恢複成一個不同的樣子。在Oracle 10G中，你就不需要這樣做了。由於控制檔案增加了一些結構，RMAN可以在一次resetlogs操作之前或之後隨時利用所有的備份來恢複資料庫。做備份使沒有必要關閉資料庫了。這一新功能意味著在一次resetlogs操作以後資料庫可以迅速的被使用者開啟。