程式師世界 >> 數據庫知識 >> Oracle數據庫 >> Oracle數據庫基礎 >> Oracle 10g R2新特性之備份和可用性特性

Oracle 10g R2新特性之備份和可用性特性

編輯：Oracle數據庫基礎

Oracle 的自身備份

到現在為止，許多開發人員已經認識到 RMAN 的潛力以及它作為數據庫備份工具的實用性。您可能還記得 RMAN 可以將數據直接備份到磁盤和磁帶。當涉及磁帶解決方案時，RMAN 使用名為介質管理庫 (MML) 的 API 來操縱磁帶子系統。

此 MML 特定於所涉及的磁帶管理系統和硬件。（例如，如果涉及 Tivoli Storage Manager，則必須使用特定的 MML — Tivoli Data Protector，RMAN 需要它來通過 Tivoli 管理磁帶。）盡管 RMAN 是數據庫引擎的一個特性，但 MML 不是引擎的一部分，而是由別人提供的；實際上，其價格可能相當高。此外，如果您的主要目的是備份 Oracle 數據庫，則在 MML 方面進行額外的投資就顯得不適當了。

在 Oracle 數據庫 10g 第 2 版中，一個名為 Oracle Secure Backup (OSB) 的新工具代替了特定於第三方磁帶管理系統的 MML，從而使此要求變得更容易接受。 OSB 可以直接備份到磁帶庫，因此您不需要任何其他介質管理層。而其最大的優點是，OSB 與數據庫引擎緊密集成，因此可以通過 Oracle Enterprise Manager 對它進行控制和管理。

但其他非數據庫備份（如備份 Oracle Home、初始化文件、集群注冊表文件（就 RAC 而言）以及其他重要文件）又如何呢？您可能會問，這些備份不需要備份工具嗎？

回答是“不需要”。就像任何獨立工具一樣，OSB 也可以執行文件系統備份。顯而易見，無需使用 MML 來進行 RMAN 備份再加上備份文件系統這一功能提供了一個低成本和簡化的備份和恢復方法。

下面介紹如何在 Oracle Enterprise Manager 中使用 MML 組件。首先，在 Oracle Enterprise Manager GUI 中選擇 Maintenance 選項卡：

從以上菜單中，選擇標題為“Configure Backup Settings”的超鏈接，隨即將顯示一個如下所示的屏幕：

注意此屏幕上的“Tape Settings”部分，您將在該部分中配置 Oracle Backup 工具。

Oracle Backup Administrative 軟件可以在一台獨立的主機上運行，在此主機中，該軟件通過數據服務器上運行的代理進行管理。在本示例中，Administrative 主機安裝在主機 proliback.proligence.com 上並在其上運行，且 Oracle Backup 工具已經安裝到 /bin/obt 目錄中。

當然，許多 DBA 仍喜歡使用命令行和編寫腳本。 OSB 提供了一個名為 obtool 的命令行工具。可以通過鍵入以下命令調用該命令行版本：obtool

該命令調出 OSB 提示符 ob>。可以在此處鍵入“help”來查看可用的命令。ob > help

或者，可以在命令名之後使用關鍵字“glossary”以獲得有關此命令的更多詳細信息：ob> help restore glossary

要備份 Oracle Home，應使用：ob> backup --level incr --at 2005/03/29.09:00　 --priority 1 --family Pool1 --privileged --dataset OracleHome --expirerequest 7days

我們需要對以上命令進行一些說明。第一個參數 (level) 指示備份級別。在此您指定了增量備份來備份自上次增量備份以來更改的所有文件。第二個參數 2005/03/29.09:00 指定備份運行的時間，即 2005 年 3 月 29 日上午 9 點。

如果有多個備份作業，那麼它們按照什麼順序執行？此順序由優先級選項（此處設置為 1，表示“最高優先級”）指定。可以指定一個小於等於 100 的值來指定較低的優先級。

您還為不同類型的備份指定了幾個介質池。例如，您可以有一個用於數據文件備份的介質池，一個用於歸檔日志的介質池，和一個用於其他非數據庫備份的介質池。此處，您將名為 Pool1 的池指定為用於此備份的池。

您已經通過參數數據集指定了要備份的文件。當您期望另一個增量備份發生時，您已經通過參數 expirerequest 請求在 7 天後使此備份過期。

我在這裡的目的是提供一個非常簡要的介紹；完整介紹將需要一本書的篇幅。有關 OSB 的更多信息，請參考可用的文檔集。

既往作業和當前作業的動態 RMAN 視圖

與許多其他 DBA 一樣，自從 Oracle8 中引入 RMAN 後不久，我便對它情有獨鐘。但我從不認為對它的活動有一個徹底的了解。

在 Oracle 數據庫 10g 第 2 版中，為 RMAN 作業提供的動態視圖簡化了對這些作業（無論是當前作業還是既往作業）的理解。

第一個新視圖 V$RMAN_BACKUP_JOB_DETAILS 記錄所有備份的歷史。除顯示像備份歷時這樣的簡單詳細信息外，此視圖還顯示了許多對事後分析很重要的其他詳細信息。下面,我們將介紹一些重要的詳細信息，以及它們如何幫助您分析 RMAN 會話。

假設您要對有關該歷史記錄的所有內容有一個或多或少的了解：已經發出的 RMAN 作業數、每個作業的狀態、這些作業的開始和完成時間、這些作業的類型等。您將按如下所示發出一個查詢：

SQL> col STATUS format a9 SQL> col hrs format 999.99 SQL> select 　2　　 SESSION_KEY, INPUT_TYPE, STATUS, 　3　　 to_char(START_TIME,'mm/dd/yy hh24:mi') start_time, 　4　　 to_char(END_TIME,'mm/dd/yy hh24:mi')　 end_time, 　5　　 elapsed_seconds/3600　　　　　　　　　 hrs 　6　from V$RMAN_BACKUP_JOB_DETAILS 　7* order by session_key

輸出可能類似如下所示：

SESSION_KEY　　INPUT_TYPE　　　STATUS　　START_TIME　　 END_TIME　　　　　HRS -----------　　-------------　 --------　-------------- -------------　　 ------- 　　　　　1　　DATAFILE FULL　 COMPLETED 03/25/05 00:48 03/25/05 00:48　　.00 　　　　　4　　DB FULL　　　　 COMPLETED 03/27/05 02:09 03/27/05 02:11　　.04 　　　　　7　　DB FULL　　　　 FAILED　　03/27/05 02:18 03/27/05 02:24　　.10

SESSION KEY 列是顯示其他相關信息的其他視圖的關鍵之處。（稍後將介紹有關該列的更多信息。）列 START_TIME 和 END_TIME 非常直觀。列 ELAPSED_SECONDS 顯示已用時間（以秒為單位），為便於閱讀，我已將該時間轉換為小時格式。 STATUS 列顯示 RMAN 作業的狀態。在該作業執行過程中，此狀態列顯示 RUNNING。

記錄的另一個重要信息是生成備份的速率以及進程讀取和數據寫入的速度。該信息可以幫助您診斷 RMAN 作業中的拖沓現象。

SQL> col ins format a10 SQL> col outs format a10 SQL> select SESSION_KEY, 　2　　 OPTIMIZED, 　3　　 COMPRESSION_RATIO, 　4　　 INPUT_BYTES_PER_SEC_DISPLAY ins, 　5　　 OUTPUT_BYTES_PER_SEC_DISPLAY outs, 　6　　 TIME_TAKEN_DISPLAY 　7　from V$RMAN_BACKUP_JOB_DETAILS 　8　order by session_key;　 SESSION_KEY OPT COMPRESSION_RATIO　　　 INS　　　　OUTS TIME_TAKEN ----------- --- ----------------- ---------- ---------- ---------- 　　　　　1 NO　　　　 2.23776224　　　3.33M　　　1.49M　00:00:06 　　　　　4 NO　　　　 1.31065794　　　6.92M　　　5.28M　00:02:16 　　　　　7 NO　　　　 1.32363058　　　3.68M　　　2.78M　00:06:00

注意如何以可讀格式（小時:分鐘:秒）顯示時間。列 INS 和 OUTS 以更易於閱讀的格式（如用 M 表示兆字節）顯示每秒的數據輸入或輸出。在以上示例中，您可以看到由會話鍵 4 標記的作業有著 6.92MB/s 和 5.2MB/s 的讀取速率。您現在可以查看多個 RMAN 執行的輸出，並從中搜索某個模式。該模式分析將幫助您識別通過波動昭示的任何潛在瓶頸。

還可以按備份類型過濾備份信息。新視圖 V$RMAN_BACKUP_JOB_DETAILS 提供了 RMAN 執行的備份類型以及輸出的組織方式。

SQL> select * from V$RMAN_BACKUP_TYPE; 　　WEIGHT INPUT_TYPE ---------- ------------- 　　　　 1 BACKUPSET 　　　　 2 SPFILE 　　　　 3 CONTROLFILE 　　　　 4 ARCHIVELOG 　　　　 5 DATAFILE INCR 　　　　 6 DATAFILE FULL 　　　　 7 DB INCR 　　　　 8 RECVR AREA 　　　　 9 DB FULL 　　對象類型 weight 決定視圖中記錄的排列順序。

另一個非常有用的視圖是 RMAN 輸出。假設您已經通過 shell 腳本運行了 RMAN 作業，但某個地方出現了故障。這樣，您就有了一個記錄 RMAN 輸出的輸出文件，但不幸的是，您已經把它給丟了。您該怎麼辦呢？幸運的是，新視圖 V$RMAN_OUTPUT 記錄 RMAN 作業中的輸出，以便稍後查看。該視圖對用腳本編制的 RMAN 作業以及即席作業很有用。

SQL> select output 　2　from v$rman_output 　3　where session_key = 4 　4　order by recid; OUTPUT ---------------------------------------------------------------------- connected to target database: TEST (DBID=1849323268) Starting backup at 27-MAR-05 using target database controlfile instead of recovery catalog allocated channel:ORA_DISK_1 channel ORA_DISK_1: sid=201 devtype=DISK channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00001 name=/u01/app/Oracle/oradata/TEST/system01.dbf input datafile fno=00003 name=/u01/app/Oracle/oradata/TEST/sysaux01.dbf input datafile fno=00002 name=/u01/app/Oracle/oradata/TEST/undotbs01.dbf input datafile fno=00004 name=/u01/app/Oracle/oradata/TEST/users01.dbf input datafile fno=00005 name=/u01/app/Oracle/oradata/TEST/accdata01.dbf channel ORA_DISK_1: starting pIEce 1 at 27-MAR-05 channel ORA_DISK_1: finished pIEce 1 at 27-MAR-05 pIEce handle=/u01/app/Oracle/product/10.2.0/db_1/dbs/07ggc7qr_1_1 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:01:46 channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset including current controlfile in backupset channel ORA_DISK_1: starting pIEce 1 at 27-MAR-05 channel ORA_DISK_1: finished pIEce 1 at 27-MAR-05 pIEce handle=/u01/app/Oracle/product/10.2.0/db_1/dbs/08ggc7u6_1_1 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03 Finished backup at 27-MAR-05

您可以看到，此處捕獲了 RMAN 作業的整個輸出。這是一個保存在內存中的視圖，在實例關閉時會從內存中清除。如果希望保存 RMAN 輸出，可以將這些行復制到一個永久表。列 SESSION_KEY 顯示與視圖 V$RMAN_BACKUP_JOB_DETAILS 中顯示的 RMAN 作業關聯的記錄。現在，您將不會再丟失 RMAN 作業中的輸出了。

通過 Oracle Enterprise Manager，您可以利用新視圖創建新備份報表。此報表提供了已經在您的企業中執行的備份操作的瞬時概要。可以按備份類型和狀態過濾數據。

為 Oracle RAC 集群動態分配通道

當然，在 Oracle RAC 環境中，有多個數據庫運行在多個主機上。但在這樣的環境中調用 RMAN 時，不得不只連接到一個實例（使用 TARGET=/）上，從而導致一個節點執行所有工作而其他節點卻相對空閒。

在 Oracle 數據庫 10g 第 2 版之前，讓兩個節點執行該工作的一個方法就是創建多個連接到多個實例的通道。以下顯示了一個相關 RMAN 命令的示例：

allocate channel = c1 type sbt_tape connect = 'rman/rmanpass@inst1'; allocate channel = c2 type sbt_tape connect = 'rman/rmanpass@inst2';

該命令假設您有兩個實例，即 inst1 和 inst2。但該選項並不完全滿足要求，這是因為它無法揭示某個節點出現了故障；當某個節點出現故障時，整個 RMAN 作業將發生故障。此外，它並不創建真正的負載平衡配置。

在 Oracle 數據庫 10g 第 2 版中，不必再為每個 RAC 節點顯式分配一個通道來執行備份；您只需為操作定義並行度即可。 RMAN 自動創建多個並行流，並根據集群資源管理器連接到負載最小的實例。除了負載平衡以外，它還提供了通道故障切換功能，以便將一個實例的連接故障切換到幸存節點。此新特性增強了 RMAN 進程的強健度。

通過 RMAN 恢復臨時文件

當您從 RMAN 備份恢復數據庫時，所需執行的第一個操作就是重新創建臨時表空間文件。由於臨時表空間不包含要恢復的永久對象，因此 RMAN 不備份它們 - 沒有必要為非永久對象浪費備份資源。但 Oracle 數據庫需要臨時表空間才能使許多操作高效運行。因此，如果 RMAN 也備份它們豈不是很好？

在 Oracle 數據庫 10g 第 2 版中，它做到了。當您恢復數據庫時，還將自動重新創建臨時表空間文件。以下是警報日志文件的片段：

ORA-01157: cannot identify/lock data file 201 - see DBWR trace file ORA-01110: data file 201: '/u01/app/Oracle/oradata/TEST/temp01.dbf' ORA-27037: unable to obtain file status Linux Error:2: No such file or directory Additional information: 3 Sun Mar 27 20:29:00 2005 Errors in file /u01/app/Oracle/admin/TEST/bdump/test_dbw0_15457.trc: ORA-01186: file 201 failed verification tests ORA-01157: cannot identify/lock data file 201 - see DBWR trace file ORA-01110: data file 201: '/u01/app/Oracle/oradata/TEST/temp01.dbf' Sun Mar 27 20:29:00 2005 File 201 not verifIEd due to error ORA-01157 Sun Mar 27 20:29:00 2005 Dictionary check complete Sun Mar 27 20:29:00 2005 SMON: enabling tx recovery Sun Mar 27 20:29:00 2005 Re-creating tempfile /u01/app/Oracle/oradata/TEST/temp01.dbf

通過 RESETLOGS 實現閃回數據庫/查詢

Oracle 數據庫 10g 引入了閃回數據庫，它通過撤消存儲在閃回日志中的更改回滾整個數據庫。但請考慮以下情形：數據庫活動正常。記錄已更新。數據庫因重做日志文件中存在的物理損壞而崩潰。使用備份控制文件從備份恢復了數據庫。使用 RESETLOGS 選項打開了數據庫。數據庫活動恢復。以正常方式更新記錄。開發人員喊到“幫幫忙”！他更新了錯誤的記錄集。他請求閃回該數據庫。

當使用 RESETLOGS 選項打開數據庫時，該數據庫從編號為 1 的 SCN 開始。因此，新配置文件不知道過去更新的 SCN 編號。由於閃回數據庫依賴 SCN 編號，因此該特性能否在該情形下起作用？

在 Oracle 數據庫 10g 第 2 版中，它將起作用，這是因為該數據庫將它的前一個副本存儲在控制文件中，並對頻繁地使用它。這種情況下將查詢前一個副本，並使用它將數據庫閃回到不同的時間，即使在同時重置了 SCN 編號的情況下也是如此。

我們來看一個示例：首先，檢查帳號 3 的帳戶持有者。

SQL> select first_name, last_name 　2　from accounts 　3　where acc_no = 3; FIRST_NAME　　　　　　　　　　 LAST_NAME ------------------------------ ----------- Alan　　　　　　　　　　　　　 Smith

現在更新名稱：SQL> update accounts 　2　set first_name = 'John' 　3　where acc_no = 3;

現在，毀壞數據庫，從備份恢復，然後在 RESETLOGS 選項中打開已恢復的數據庫。

假設一段時間過後，大廳角落裡傳來了一個氣急敗壞的聲音“靠”，然後就有人請您將數據庫閃回到先前的某個時間點，而這個時間點恰好位於 RESETLOGS 操作之前。

這時只需發出以下命令即可。SQL> Flashback database to before resetlogs;

該命令恰好把數據庫閃回到 RESETLOGS 之前的 SCN。執行該命令後，再次檢查該表。

您可以看到，RESETLOGS 操作沒有影響閃回操作。

該特性使閃回數據庫非常強大和有用。它的行為對閃回查詢也適用。

閃回數據庫中的恢復點

還記得 SQL 中保存點的概念嗎？在一個事務中，您可以創建保存點，進行某些修改，創建另一個保存點，等等。如果這些更改不是您想要的，則您所要做的就是將它們回滾到某個具體的保存點。

現在，我們將介紹 Oracle 數據庫 10g 中引入的一個新功能 — 閃回數據庫。通過它您可以將數據庫倒回到前一個時間點。在這種情況下擁有一個與保存點類似的功能（即能夠倒回到一個有名稱的點，而不僅僅是一個時間點）豈不是很好？

在 Oracle 數據庫 10g 第 2 版中，您可以使用一個名為恢復點的新功能來實現該操作。以下是它的工作方式。假設有一個長期運行的處理（涉及多個必須按順序運行的批處理程序）。以下是事件序列：創建恢復點 rp1 運行批處理作業 1 創建恢復點 rp2 運行批處理作業 2 等等。批處理作業 2 在執行過程中失敗，您需要將數據庫恢復到一致的狀態。您不必將它一直恢復到運行的開始階段。由於恢復點 rp2 是在批處理作業執行之前創建的，因此只需將數據庫閃回到該恢復點。

使用以下代碼創建一個恢復點

create restore point before_monthend_200503;

現在根據當前的數據庫時間和 SCN 創建了恢復點 BEFORE_MONTHEND_200503。如果要確保可以將數據庫閃回到某個特定恢復點，可以通過按如下所示創建有保證的恢復點來指定 guarantee：

create restore point before_monthend_200503 guarantee Flashback database;

可以通過從動態性能視圖 V$RESTORE_POINT 中執行 SELECT 來確認該恢復點是否存在：

SQL> select * from v$restore_point; 　　　 SCN DATABASE_INCARNATION# GUA STORAGE_SIZE ---------- --------------------- --- ------------ TIME --------------------------------------------------- NAME --------------------------------------------------- 　 1429811　　　　　　　　　　 1 YES　　　8192000 27-MAR-05 05.18.39.000000000 PM BEFORE_MONTHEND_200503

稍後當您要將數據庫閃回到該恢復點時，您只需發出：

Flashback database to restore point before_monthend_200503;

如果檢查警報日志，它將顯示一個類似如下的行：

Media Recovery ApplIEd UNTIL CHANGE 1429814

恢復點（尤其是有保證的恢復點）在許多與數據庫相關的任務中非常有用。 QA 數據庫就是一個典型示例。在該數據庫中，您可能要建立一個恢復點、運行某些測試並閃回到恢復點，從而使數據庫看起來好象什麼也沒發生一樣。然後，您可以執行另一輪測試，並再次將它恢復到恢復點。

研究快速恢復區

您可能已經配置了快速恢復區來備份不同類型的文件。但您怎麼知道其中有哪些可用的備份類型呢？

一個新視圖 V$Flash_RECOVERY_AREA_USAGE 顯示了快速恢復區中可用的備份類型。

SQL> select * from V$Flash_RECOVERY_AREA_USAGE; 　　　　FILE_TYPE　　PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES 　　　　------------ ------------------ ------------------------- --------------- 　　　　CONTROLFILE　　　　　　　　　 0　　　　　　　　　　　　 0　　　　　　　 0 　　　　ONLINELOG　　　　　　　　　　 0　　　　　　　　　　　　 0　　　　　　　 0 　　　　ARCHIVELOG　　　　　　　　　.02　　　　　　　　　　　 .02　　　　　　　 1 　　　　BACKUPPIECE　　　　　　　 68.98　　　　　　　　　　　1.02　　　　　　　10 　　　　IMAGECOPY　　　　　　　　　　 0　　　　　　　　　　　　 0　　　　　　　 0 　　　　FlashBACKLOG　　　　　　　　.95　　　　　　　　　　　　 0　　　　　　　 3

使用該視圖，您可以立即看到快速恢復區中的可用文件類型。但它只顯示百分比，因此您如何確定實際值？只需查詢視圖 $RECOVERY_FILE_DEST 即可。

SQL> select * from V$RECOVERY_FILE_DEST; NAME ---------------------------------------------------------- SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES ----------- ---------- ----------------- --------------- /home/Oracle 2147483648 1502122496　　　　　22201856　　　　　　　14

該查詢顯示恢復區的總大小為 16384000。閃回日志占用 SPACE_LIMIT 列的 0.95%（上一個查詢中所示），因此您可以計算所占用空間的實際大小。它還顯示了從快速恢復區中不同類型的備份中可以回收的空間大小。例如，您可以因為備份可能已過期而回收 1.02% 的已占用空間。使用該視圖，您可以針對快速恢復區使用率和大小進行智能化的預測。

Oracle Enterprise Manager 通過向 Recovery Settings 頁（顯示快速恢復區域中的文件細分）中添加一個餅圖來利用新的 V$RECOVERY_FILE_DEST 視圖：