RMAN 的功能更強大，它具有重新設(shè)計的增量備份模式、增量備份的脫機恢復(fù)、預(yù)覽恢復(fù)、復(fù)原日志進行恢復(fù)、文件壓縮等功能。

大多數(shù)人都認同 RMAN 是用于 Oracle 數(shù)據(jù)庫備份的實際工具。但是與它們所具有的強大功能相比， RMAN 的早期版本 并未提供人們所期待的一些功能。就像許多 DBA 一樣，如果它沒有包含我認為必須具有的功能，我將會異常惱怒。

幸運的是， Oracle 數(shù)據(jù)庫 10 g 通過合并人們所想要的許多功能解決了很多這類問題，這使 RMAN 成為一種更強大、更有用的工具。讓我們看一下這些功能。

再論增量備份

RMAN 包含一個用于增量備份的選項。但是老實講，您多久使用一次呢？可能經(jīng)常用，也可能永遠也不會用。

該選項用于指示該工具以相同或較低的級別來備份自上一次增量備份后發(fā)生改變的塊。例如，在第 1 天采用完全備份 (level_0) ，而在第 2 、 3 天采用兩個 level_1 的增量。后面的兩個備份只是備份了第 1 天和第 2 天之間，及第 2 天和第 3 天之間更改過的塊，而不是跨整個備份時間進行備份。這種策略減少了備份規(guī)模、需要的空間較少，并縮小了備份窗口，減少了網(wǎng)絡(luò)間移動的數(shù)據(jù)量。

執(zhí)行增量備份的最重要的原因是：與數(shù)據(jù)倉庫環(huán)境關(guān)聯(lián)起來，在該環(huán)境中許多操作都是在 NOLOGGING 模式下執(zhí)行的，并且數(shù)據(jù)更改不會涉及到存檔的日志文件 — 因此，不可能發(fā)生介質(zhì)恢復(fù)。考慮到今天的數(shù)據(jù)倉庫的巨大規(guī)模，以及其中的大部分數(shù)據(jù)并沒有發(fā)生改變的事實，就會知道執(zhí)行完全備份既不值得又不實際。相反，在 RMAN 中執(zhí)行增量備份是一個理想的選擇。

既然如此，那么為什么許多 DBA 極少執(zhí)行增量備份呢？一個原因是：在 Oracle 9 i 及其較低的版本中， RMAN 會掃描所有的數(shù)據(jù)塊以確定要備份的內(nèi)容。這個過程給系統(tǒng)施加了如此大的壓力，以致于執(zhí)行增量備份變得不實際。

Oracle 數(shù)據(jù)庫 10 g RMAN 以消除了該缺陷的方式來執(zhí)行增量備份。它使用一個文件，類似于文件系統(tǒng)中的日志，來跟蹤自上一次備份起更改過的塊。 RMAN 讀取該文件來確定將要備份的塊。

您可以通過發(fā)布以下命令來啟用該跟蹤機制：

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

該命令將創(chuàng)建一個名為 /rman_bkups/change.log 的二進制文件，以用于跟蹤。相反，您可以使用以下命令來禁用跟蹤：

SQL> alter database disable block change tracking;

要想查看當前是否啟用了對更改的跟蹤，您可以查詢：

SQL> select filename, status from v$block_change_tracking;

快速恢復(fù)區(qū)

在 Oracle 9 i 中引入的閃回查詢，依賴于撤消表空間來閃回到先前的版本，因此限制了它深入到過去的能力。快速恢復(fù)通過創(chuàng)建閃回日志提供了一個可選的解決方案，它類似于重做日志，用于將數(shù)據(jù)庫恢復(fù)到先前的狀態(tài)。 總之，您為數(shù)據(jù)庫創(chuàng)建了一個快速恢復(fù)區(qū)，指定了其大小，并用如下 SQL 命令將數(shù)據(jù)庫置于快速恢復(fù)模式下：

alter system set db_recovery_file_dest = '/ora_flash_area';

alter system set db_recovery_file_dest_size = 2g ;

alter system set db_flashback_retention_target = 1440;

alter database flashback on;

該數(shù)據(jù)庫必須處于存檔日志模式下以支持閃回。此過程在目錄 /ora_flash_area 中創(chuàng)建了 Oracle 管理文件，其總大小高達 2GB 。對數(shù)據(jù)庫所作的更改將寫入到這些文件中，并且可用于將數(shù)據(jù)庫快速恢復(fù)到過去的某個點上。

默認情況下， RMAN 還使用 /ora_flash_area 來存儲備份文件；因此， RMAN 是存儲在磁盤上，而不是磁帶上。鑒于此，您就有能力指定您需要備份的天數(shù)。在該期限之后，如果需要更多的空間，則會自動將這些文件刪除。

快速恢復(fù)區(qū)不必是一個文件系統(tǒng)或一個目錄，但是 — ，它可以是一個自動存儲管理 (ASM) 磁盤組。如果是那樣的話，就可以通過如下命令來指定快速恢復(fù)區(qū)：

alter system set db_recovery_file_dest = '+dskgrp1';

因此，結(jié)合使用 ASM 和 RMAN ，您就可以使用廉價的磁盤（如 Serial ATA 或 SCSI 驅(qū)動）來構(gòu)建一個高度可伸縮的、容錯能力強的存儲系統(tǒng)，而不需要額外的軟件。（有關(guān) ASM 的詳細信息，請參閱本系列中的 第 8 周 的內(nèi)容。）此過程不但使存儲過程更快，也使之能用足夠便宜的、基于磁帶的方法來完成。

一個額外的好處是防止用戶錯誤。由于 ASM 不是真正的文件系統(tǒng)，使其遭受 DBA 和系統(tǒng)管理員意外破壞的可能性也更小一些。

增量合并

假如您有如下備份計劃：

星期天 - 第 0 級（完全），帶有標簽 level_0
星期一 - 第 1 級（增量），帶有標簽 level_1_mon
星期二 - 第 1 級（增量），帶有標簽 level_1_tue

等等。如果數(shù)據(jù)庫在星期天發(fā)生故障，在 Oracle 10 g 之前的版本中，您將不得不恢復(fù)標簽 level_0 ，然后應(yīng)用所有六個增量。它將持續(xù)一段較長的時間，這是許多 DBA 不進行增量備份的另一個原因。

Oracle 數(shù)據(jù)庫 10 g RMAN 從根本上改變了此格局?，F(xiàn)在，您的增量備份命令看起來如下所示：

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

在此，我們指示 RMAN 進行 level_1 增量備份，并將其與帶有 level_0 標簽的完全備份副本合并。在執(zhí)行該命令之后， level_0 就成為了那一天的完全備份。

因此，在星期二，帶有標簽 level_0 的備份，當將其與 level_1 增量備份合并時，它就變得與完全的星期二備份相等。同樣地，對于星期六采用的增量，當采用磁盤上的備份時，它將會與完全的 level_0 星期六備份相等。如果數(shù)據(jù)庫在星期六發(fā)生故障，您只需恢復(fù) level_0 備份外加一小份存檔日志，使數(shù)據(jù)庫一致；在此不需要應(yīng)用額外的增量。該方法顯著地削減了恢復(fù)時間、加快了備份速度，并消除了再一次執(zhí)行完全的數(shù)據(jù)庫備份的需要。

壓縮文件

對于快速恢復(fù)區(qū)中基于磁盤的備份，仍有一個大的限制：磁盤空間。特別是當經(jīng)網(wǎng)絡(luò)進行時 — 通常情況下就是這樣 — 那么創(chuàng)建一個盡可能小的備份集是明智的。在 Oracle 數(shù)據(jù)庫 10 g RMAN 中，您可以在備份命令內(nèi)部壓縮文件：

RMAN> backup as compressed backupset incremental level 1 database;

注意子句 COMPRESSED 的用法。它將用一個顯著不同的方式壓縮備份文件：在恢復(fù)時， RMAN 不用解壓縮就能讀取文件。為了確認壓縮，檢查如下的輸出信息：

channel ORA_DISK_1:starting compressed incremental level 1 datafile backupset

此外，您可以通過檢查 RMAN 列表輸出來驗證備份已被壓縮：

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_03w 2m3 lr_.bkp

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

SPFILE Included:Modification time:26-FEB-04

對于任意的壓縮過程，該方法都會對 CPU 產(chǎn)生壓力。作為折衷，您可以在磁盤上保存更多的 RMAN 備份，它準備好為還原和恢復(fù)操作所用。此外，您可以在物理備用數(shù)據(jù)庫上制作 RMAN 備份，它可用于恢復(fù)初始的數(shù)據(jù)庫。該方法將備份源卸載到另一臺主機上。

在您開始行動之前先看看：恢復(fù)預(yù)覽

在 Oracle 數(shù)據(jù)庫 10 g 中， RMAN 通過提供執(zhí)行恢復(fù)操作所需要的預(yù)覽備份的能力向前邁進了一大步。

RMAN> restore database preview;

列表 1 顯示了該操作的輸出結(jié)果。您還可以預(yù)覽特定的恢復(fù)操作；例如：

restore tablespace users preview;

預(yù)覽允許您通過執(zhí)行周期性的、有規(guī)則的檢查，來確保您的備份基礎(chǔ)架構(gòu)的恢復(fù)準備就緒。

Resetlogs 和恢復(fù)

假設(shè)您丟失了當前的聯(lián)機重做日志文件，并且您不得不執(zhí)行一個不完全的數(shù)據(jù)庫恢復(fù) — 一種很少見但聽說過的情況。最大的問題是 resetlogs ；在不完全的恢復(fù)之后，您必須用 resetlogs 子句打開數(shù)據(jù)庫，它把日志線程的序列號設(shè)置為 1 ，會使您的 RMAN 中的早期備份作廢并使恢復(fù)操作面臨更多的挑戰(zhàn)。

在 Oracle 9 i 及其較低的版本中，如果您需要將數(shù)據(jù)庫恢復(fù)到執(zhí)行 resetlogs 操作之前的某個版本，您將不得不恢復(fù)到一個不同的拷貝。在 Oracle 數(shù)據(jù)庫 10 g 中，您不必這樣做。由于控制文件中額外的基礎(chǔ)架構(gòu)，在執(zhí)行 resetlogs 之前或之后， RMAN 現(xiàn)在都可以容易地使用所有備份來恢復(fù) Oracle 數(shù)據(jù)庫。它不需要關(guān)閉數(shù)據(jù)庫來制作一個備份。這種新功能意味著在執(zhí)行 resetlogs 操作之后，可以立即為用戶社區(qū)重新打開數(shù)據(jù)庫。

為 RMAN 作好準備

Oracle 數(shù)據(jù)庫 10 g RMAN 中的增強功能使它成為您的備份策略中的甚至更具強制性的工具。對增量備份過程的改進只會使 RMAN 難以被忽視。

有關(guān) Oracle 10 g 中的 RMAN 的更多信息，請參閱 Oracle Database Backup and Recovery Basics 10g 第 1 版 (10.1) 中 第 4 章 的內(nèi)容。