溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下Oracle11g備份恢復新特性有哪些，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
還記得 Oracle Database 10g 中引入的閃回日志記錄嗎？如果數據庫中已啟用了閃回功能，閃回日志會將更改塊的以前映像的優化版本記錄到在閃回恢復區生成的閃回日志中。這些日志可以幫助您將數據庫閃回到過去的一個時間點，而不必從備份中執行時間點恢復。
那么，既然這些閃回日志包含塊的以前的映像，為什么不將它們也用于恢復呢？Oracle Database 11g 正是這么做的。當您恢復特定的塊時，Oracle 會在閃回日志（而不是數據文件）中查找該塊的以前映像的良好副本，然后應用存檔日志以使其向前滾動。由于無需借助備份，該方法可以節省很多時間，尤其是當備份在磁帶上時。
RMAN 在 Oracle Database 10g 中提供了備份段壓縮功能以節省網絡帶寬，但是許多人都不輕易使用它。為什么？因為第三方壓縮工具提供的方法比 RMAN 自身的更快。但是，RMAN 10g 壓縮具備一些第三方壓縮工具所沒有的好用功能。例如，當 RMAN 10g 還原數據文件時，不需要先解壓縮這些文件（如果以前被壓縮過）。該方法在還原期間可以顯著節省帶寬。
在 Oracle Database 11g 中，RMAN 提供了另一種算法 ZLIB，以前使用的是 BZIP2。ZLIB 算法要快得多，但是不能壓縮太多內容。另一方面，它也很節省 CPU。因此，如果您的 CPU 不多，最好使用 ZLIB 壓縮。（注意，版本 11.1 中的默認選件是 BZIP2；您需要購買一個新選件 Advanced Compression Option 才能使用 ZLIB。）
要使用 ZLIB 壓縮，只需將 RMAN 配置參數設置為：
RMAN> configure compression algorithm 'ZLIB' ;
如果您以前更改過該參數，需要發出上述命令。要將其更改為 BZIP2，發出以下命令：
RMAN> configure compression algorithm 'bzip2';
現在，所有壓縮備份都將使用新算法。
您或許已經知道您可以并行備份，方法是，聲明多個通道使每個通道成為一個 RMAN 會話。但是，很少有人意識到每個通道一次只能備份一個數據文件。因此，即使有多個通道，但是每個數據文件只通過一個通道進行備份，這與備份真正并行的概念有些相反。
在 Oracle Database 11g RMAN 中，通道可以將數據文件拆分為塊，這些塊被稱為“段”。您可以指定每個段的大小。下面就是一個例子：
RMAN> run {
2> allocate channel c1 type disk format '/backup1/%U';
3> allocate channel c2 type disk format '/backup2/%U';
4> backup
5> section size 500m
6> datafile 6;
7> }
該 RMAN 命令分配兩個通道并在兩個通道上并行備份用戶的表空間。每個通道占用數據文件的一個 500MB 的段并以并行方式備份該文件。這加快了大型文件的備份速度。
以這種方式備份時，備份的內容也顯示為段。
RMAN> list backup of datafile 6; ... <snipped> ... List of Backup Pieces for backup set 901 Copy #1 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 2007 1 AVAILABLE /backup1/9dhk7os1_1_1 2008 2 AVAILABLE /backup2/9dhk7os1_1_1 2009 3 AVAILABLE /backup1/9dhk7os1_1_3 2009 3 AVAILABLE /backup2/9dhk7os1_1_4
注意，備份段是如何顯示為文件段的。由于每個段去往不同的通道，因此您可以將它們定義為不同的掛載點（如 /backup1 和 /backup2），您還可以并行方式將它們備份到磁帶。
但是，如果 6 號大型文件只位于一個磁盤上，使用并行備份就沒有優勢了。如果您對該文件進行分段，磁頭需要不斷移動來處理該文件的不同段，其缺點勝過分段的優點。
您已經知道撤銷數據的用途。當事務更改某個塊時，該塊以前的映像將被保存在撤銷段中。即使事務已提交，數據仍然保存在那里，因為在該塊被更改之前啟動的某個運行時間較長的查詢可能會請求已更改和提交的塊。該查詢應該獲取該塊以前的映像，即之前提交的映像而不是當前的映像。因此，即使在提交之后，撤銷數據仍然保存在撤銷段中。隨著時間的推移，該數據會被沖刷出撤銷段以便為新插入的撤銷數據騰出空間。
當 RMAN 備份運行時，它會備份撤銷表空間中的所有數據。在恢復期間，與提交的事務相關的撤銷數據將不再需要，因為它們已經在重做日志流中，或者仍然在數據文件中（如果已從緩沖區清除已使用的塊并將其寫入磁盤），可以從那里進行恢復。那么，為什么還要備份提交的撤銷數據呢？
在 Oracle Database 11g 中，RMAN 很智能：它不備份恢復所不需要的已提交撤銷數據。而對恢復至關重要的未提交撤銷數據照常備份。這減少了備份（以及恢復）的大小和時間。
在許多數據庫中，尤其是在事務提交更加頻繁，撤銷數據在撤銷段中的存留時間更長的 OLTP 數據庫中，大多數撤銷數據實際上已被提交。因此，RMAN 只需備份撤銷表空間中的幾個塊。
最好的是，您不需要做任何事即可實現該優化，Oracle 會自行操作。
您可能會使用一個目錄數據庫作為 RMAN 信息庫。如果沒有，您應該認真地考慮使用一個目錄數據庫。這有很多優點，例如報告、控制文件受損時簡化恢復，等等。
現在，又出現了一個問題：多少個目錄合適？通常，只創建一個目錄數據庫作為所有數據庫的信息庫是合理的。但是，要考慮到安全性，這可能不是一個好方法。目錄擁有者將能夠查看所有數據庫的所有信息庫。由于每個要備份的數據庫可能都有一個單獨的 DBA，因此不應該讓該目錄可見。
那么，還有什么別的方法嗎？當然，您可以為每個目標數據庫都創建一個單獨的目錄數據庫，可是考慮到成本，這或許不太實際。另一種方法是仍然只創建一個目錄數據庫，但是為每個目標數據庫都創建一個虛擬目錄。虛擬目錄是 Oracle Database 11g 中的新增功能。我們來看看如何創建虛擬目錄。
首先，您需要創建一個包含所有目標數據庫的基目錄。假設擁有者為“RMAN”。從目標數據庫，以基用戶身份連接到目錄數據庫并創建目錄。
$ rman target=/ rcvcat rman/rman@catdb
Recovery Manager: Release 11.1.0.6.0 - Production on Sun Sep 9 21:04:14 2007 Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: ODEL11 (DBID=2836429497)
connected to recovery catalog database
RMAN> create catalog;
recovery catalog created
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
這稱為基目錄，歸用戶“RMAN”所有。現在，我們再創建兩個將擁有各自的虛擬目錄的用戶。為簡單起見，我們讓這兩個用戶的名稱與目標數據庫相同。仍然以基目錄擁有者 (RMAN) 的身份保持連接，同時發出以下語句：
RMAN> grant catalog for database odel11 to odel11; Grant succeeded.
現在，使用虛擬目錄擁有者 (odel11) 的身份連接，并發出 create virtual catalog 語句：
$ rman target=/ rcvcat odel11/odel11@catdb RMAN> create virtual catalog; found eligible base catalog owned by RMAN created virtual catalog against base catalog owned by RMAN
現在，在同一 RMAN 信息庫中注冊另一個數據庫 (PRONE3)，并為其同名數據庫創建一個虛擬目錄擁有者“prone3”。
RMAN> grant catalog for database prone3 to prone3; Grant succeeded. $ rman target=/ rcvcat prone3/prone3@catdb RMAN> create virtual catalog; found eligible base catalog owned by RMAN created virtual catalog against base catalog owned by RMAN
現在，如果您希望查看已注冊的數據庫，以基目錄擁有者 (RMAN) 的身份連接，您將看到：
$ rman target=/ rcvcat=rman/rman@catdb RMAN> list db_unique_name all; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- ----------------- --------------- ------------------ 285 PRONE3 1596130080 PRIMARY PRONE3 1 ODEL11 2836429497 PRIMARY ODEL11
和預料的一樣，它顯示了兩個注冊的數據庫。現在，以 ODEL11 的身份連接并發出同一命令：
$ rman target=/ rcvcat odel11/odel11@catdb RMAN> list db_unique_name all; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- ----------------- --------------- ------------------ 1 ODEL11 2836429497 PRIMARY ODEL11
注意如何只列出一個數據庫，而不是兩個全列出。該用戶 (odel11) 只允許查看一個數據庫 (ODEL11)，即上面顯示的數據庫。您可以通過以另一個擁有者 PRONE3 的身份連接到目錄對此進行驗證：
$ rman target=/ rcvcat prone3/prone3@catdb RMAN> list db_unique_name all; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- - ---------------- --------------- ------------------ 285 PRONE3 1596130080 PRIMARY PRONE3
利用虛擬目錄，您可以僅為 RMAN 信息庫目錄維護一個數據庫，但要建立安全邊界以使各個數據庫擁有者管理其自己的虛擬信息庫。一個通用的目錄數據庫可以簡化管理、降低成本以及在提高數據庫可用性的同時降低成本。
仍然是多個目錄這個主題，讓我們來考慮另外一個問題。既然您已經了解如何在相同的基目錄上創建虛擬目錄，您可能看到了將所有這些獨立的信息庫整合到一個信息庫中的必要性。
一個選擇是在各自的目錄中取消目標數據庫的注冊，然后將它們重新注冊到新的中央目錄。但是，這樣做意味著會丟失存儲在這些信息庫中的所有有價值的信息。當然，您可以同步控制文件，然后再重新同步到目錄，但是這樣會使控制文件變得很大，而且不實際。
Oracle Database 11g 提供了一個新特性：合并目錄。實際上，該功能是將目錄從一個數據庫導入另一個數據庫，或者換句話說，就是“移動”目錄。
讓我們看一下它的工作原理。假設您希望將目錄從數據庫 CATDB1 移到另一個名為 CATDB2 的數據庫中。首先，連接到目錄數據庫 CATDB2（目標）：
$ rman target=/ rcvcat rman/rman@catdb2 Recovery Manager: Release 11.1.0.6.0 - Production on Sun Sep 9 23:12:07 2007 Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database: ODEL11 (DBID=2836429497) connected to recovery catalog database
如果該數據庫已經有一個用戶“RMAN”擁有的目錄，那么轉至下一導入步驟；否則，您將需要創建該目錄：
RMAN> create catalog; recovery catalog created
現在，從遠程目錄 (catdb1) 導入：
RMAN> import catalog rman/rman@catdb1; Starting import catalog at 09-SEP-07 connected to source recovery catalog database import validation complete database unregistered from the source recovery catalog Finished import catalog at 09-SEP-07 starting full resync of recovery catalog full resync complete
上面的輸出中有一些重要信息。注意，目標數據庫如何取消了在其原始目錄數據庫中的注冊。現在，如果您檢查這個新目錄中的數據庫名稱：
RMAN> list db_unique_name all; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- ----------------- --------------- ------------------ 286 PRONE3 1596130080 PRIMARY PRONE3 2 ODEL11 2836429497 PRIMARY ODEL11
您將注意到 DB Key 已更改。ODEL11 以前為 1，現在為 2。
上面的操作會將所有已注冊的目標數據庫的目錄導入目錄數據庫。有時，您可能不希望這樣，而只希望導入一個或兩個數據庫。要進行以上操作，可以發出以下命令：
RMAN> import catalog rman/rman@catdb3 db_name = odel11;
這會再次更改 DB Key。
如果您不希望在導入期間取消導入數據庫在源數據庫中的注冊，該如何操作呢？換句話說，您希望讓數據庫在兩個目錄數據庫中都有注冊。您將需要使用“no unregister”子句：
RMAN> import catalog rman/rman@catdb1 db_name = odel11 no unregister;
這將確保數據庫 ODEL11 不會在目錄數據庫 catdb1 中取消注冊，同時又在新的目錄中進行了注冊。
您由于各種原因需要復制數據庫，例如搭建 Data Guard 環境、根據生產數據庫建立臨時數據庫或 QA 數據庫，或將數據庫移到新平臺中。RMAN 中的 DUPLICATE 命令極大地簡化了該活動。但是，RMAN 從哪里復制數據庫呢？
最顯而易見的選擇就是從主數據庫本身進行復制。主數據庫是最新的版本，具有復制數據庫所需的全部信息。但是，雖然該方法很方便，它還是會給主數據庫帶來一些壓力。此外，該方法需要一個到主數據庫的專用連接，而這并不總是能實現。
生產數據庫的另一個源是數據庫備份。這不會影響生產數據庫，因為我們將單獨進行備份。雖然從 Oracle9i Database 開始，就可以從數據庫的備份中復制數據庫了，但使用中仍有些困難：盡管復制的源是備份，但此過程仍需要一個到主數據庫的連接。因此，存在以下問題：如果主數據庫因進行維護性關閉而不可用，該怎么辦呢？或者您從其他服務器復制數據庫，而該服務器由于某些安全性或其他邏輯原因無法連接到主數據庫，又該怎么辦呢？
Oracle Database 11g 第 2 版解決了這一問題。在該版本中，無需連接到主數據庫即可執行復制數據庫任務。您只需備份文件。我們通過示例了看一下如何復制數據庫。
首先，為了說明概念，我們需要從主數據庫執行一次備份。我們從啟動 RMAN 作業開始。
# $ORACLE_HOME/bin/rman target=/ rcvcat=rman_d112d1/rman_d112d1@d112d2
Recovery Manager: Release 11.2.0.1.0 - Production on Sun Aug 8 10:55:05 2010 Copyright (c) 1982, 2009,
Oracle and/or its affiliates. All rights reserved. connected to target database: D112D1 (DBID=1718629572)
雖然到目錄數據庫的連接使該操作更簡單，但不是絕對必要的。首先要向您顯示使用目錄連接的步驟。
RMAN> backup database plus archivelog format '/u01/oraback/%U.rmb';
Starting backup at 08/08/10 12:08:29 current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=58 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=631 RECID=344 STAMP=726057709
input archived log thread=1 sequence=632 RECID=345 STAMP=726058637
…
… output truncated …
還需要控制文件備份。如果您配置了控制文件自動備份，則備份也包含控制文件。如果您希望確保備份控制文件，或者尚未配置控制文件自動備份，則可以顯式備份控制文件。
RMAN> backup current controlfile format '/u01/oraback/%U.rmb';
上述命令將在目錄 /u01/oraback 中創建備份文件。當然，如果您在某個位置中有了備份，則不需要執行此步驟。將這些備份文件復制到要在其上創建重復副本的服務器。
# scp *.rmb oradba2:`pwd`
在繼續操作之前，您需要知道一條信息，那就是源數據庫的 DBID。您可以通過以下三種方式之一獲取該信息：
從數據字典中獲取
SQL> select dbid from v$database;
DBID
----------
1718629572
從 RMAN 信息庫（目錄或控制文件）中獲取
RMAN> list db_unique_name all;
List of Databases
DB Key DB Name DB ID Database Role Db_unique_name
------- ------- ----------------- --------------- ------------------
2 D112D1 1718629572 PRIMARY D112D1
通過查詢目錄數據庫上的恢復目錄表獲取。
在本案例中，DBID 為 1718629572；請記下該值。（操作中并非絕對需要 DBID，但您稍后將看到它為什么如此重要。）
您還需要知道另一個非常重要的事實：備份的完成時間。您可以通過多個來源獲取該時間，最常用的一個來源是 RMAN 日志文件。否則，只需查詢 RMAN 信息庫（目錄或控制文件）。下面是操作步驟：
# $ORACLE_HOME/bin/rman target=/ rcvcat=rman_d112d1/rman_d112d1@d112d2
Recovery Manager: Release 11.2.0.1.0 - Production on Mon Aug 9 12:25:36 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: D112D1 (DBID=1718629572)
connected to recovery catalog database
RMAN> list backup of database;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -----------------
716 Full 2.44G DISK 00:03:58 08/09/10 10:44:52
BP Key: 720 Status: AVAILABLE Compressed: NO Tag: TAG20100809T104053
Piece Name: /u01/oraback/22lktatm_1_1.rmb
List of Datafiles in backup set 716
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ----------------- ----
1 Full 13584379 08/09/10 10:40:55 +DATA/d112d1/datafile/system.256.696458617
… output truncated …
需要設置 NLS 變量，因為我們需要知道具體時間，而不只是日期。從輸出中，我們知道備份的執行時間為 8 月 9 日上午 10:44:53。
其余步驟在目標主機上執行。此處，主數據庫名為 D112D1，副本數據庫名為 STG。
在文件 /etc/oratab 中添加一行以反映要復制的數據庫實例：
STG:/opt/oracle/product/11.2.0/db1:N
現在，將 Oracle SID 設置為已復制數據庫的 SID：
# . oraenv
ORACLE_SID = [STG] ?
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2.0/db1 is /opt/oracle
從主數據庫中復制初始化參數文件。編輯該文件以反映可能適當的新位置，例如審計轉儲目標、數據文件位置等。還要創建口令文件。
# orapwd file=orapwSTG password=oracle entries=20
當 pfile 文件和口令文件準備就緒后，使用 nomount 選項啟動實例。只啟動實例，這很重要，因為復制過程將創建并掛載控制文件。
SQL> startup nomount
ORACLE instance started.
Total System Global Area 744910848 bytes
Fixed Size 1339120 bytes
Variable Size 444596496 bytes
Database Buffers 293601280 bytes
Redo Buffers 5373952 bytes
雖然并不重要，但將命令放入腳本中并從 RMAN 命令行執行腳本，而不是逐行輸入每個命令，會更加輕松。下面是腳本文件的內容：
connect auxiliary sys/oracle
connect catalog rman_d112d1/rman_d112d1@d112d2
duplicate database 'D112D1' DBID 1718629572 to 'STG'
until time "to_date('08/09/10 10:44:53','mm/dd/yy hh34:mi:ss')"
db_file_name_convert = ("+DATA/D112D1","/u01/oradata/stg")
backup location '/u01/oraback' ;
該腳本是代碼式自說明的。前兩行代碼說明到輔助實例（我們要作為主數據庫副本創建的數據庫）的連接和目錄連接。第三行說明我們要將數據庫 D112D1 復制到 STG。此處還顯示了數據庫應該恢復到的時間的時間戳。由于主機之間的數據庫文件位置不同，因此用第五行加以說明。在主數據庫上，數據文件位于 ASM 磁盤組 DATA 上，而臨時數據庫將在目錄 /u01/oradata 中創建。這意味著我們必須執行命名約定更改。主數據庫 +DATA/somefile.dbf 上的數據文件名為 /u01/oradata/somefile.dbf。最后，我們提供了備份文件的位置。
在此，我們使用了時間戳 8 月 9 日 10:44:53，僅比備份完成時間晚一秒鐘。當然，只要存檔日志可用，我們在此可以使用任何其他時間。您還可以提供 SCN 號，而不是時間戳。
讓我們將該腳本文件命名為 duplicate.rman。創建之后，直接從 RMAN 調用該腳本：
#$ORACLE_HOME/bin/rman @duplicate.rman
此處為結果輸出。如果您的操作進展不太順利，將該輸出與您的情況進行比較，可能會為您提供有價值的線索。
就是這樣；臨時數據庫 STG 現在已啟動并正在運行。現在，您可以連接到該數據庫并選擇表。在此過程中，您都不必連接到主數據庫。只需幾個命令即可。
總之，正如您在輸出中所見，該命令執行以下步驟：
創建 SPFILE
關閉實例并使用新 spfile 重新啟動它
從備份中還原控制文件
掛載數據庫
執行數據文件還原。在此階段，它將用轉換后的名稱創建文件。
將數據文件恢復到指定的時間并打開數據庫
如果您想查看剛創建的數據庫的 DBID，執行以下命令：
SQL> select dbid from v$database; DBID ---------- 844813198
該 DBID 與主數據庫的 DBID 不同，因此也可使用相同目錄單獨對其進行備份。說到 DBID，還記得我們在復制過程中使用過它嗎（即使不是絕對必要的）？這是因為兩個數據庫可能具有相同的名稱，但在恢復目錄中，可能存在兩個名為 D111D1 的數據庫（源）。復制過程如何知道要復制哪個數據庫呢？于是，使用 DBID 加以明確區別。
類似地，如果您具有多個備份，RMAN 將根據 UNTIL TIME 子句自動選擇從哪個備份中復制。最后，我們在此使用了目錄數據庫；但是，該數據庫不是必需的。如果您沒有指定目錄，則必須使用“until time”子句，而不是“until SCN”。
比如說您要清理數據庫中的垃圾，于是希望刪除可能早已不存在的用戶創建的所有小型和大型表空間。刪除這些表空間時，您不經意地刪除了一個非常關鍵的表空間。該怎么辦？
在以前代碼版本中，可選方案是減少表空間總數。下面是執行步驟：
創建另一個名為 TEMPDB 的實例
還原已刪除表空間和其他必需表空間（如 SYSTEM、SYSAUX 和 UNDO）的數據文件
將其恢復到正好發生故障的時刻，務必小心，確保不會錯誤地將其向前滾動到發生刪除之前的時刻
從 TEMPDB 傳輸表空間并將其插入到主數據庫中
刪除 TEMPDB 實例
毋庸置疑，這些步驟對于任何人來說都是復雜的，除非是習慣于經常刪除表空間的經驗豐富的 DBA。您不希望具有類似于取消刪除表（閃回表）功能的簡單的“取消刪除表空間”功能嗎？
在 Oracle Database 11g 第 2 版中，您將如愿以償。我們來看一下它的工作原理。為了進行說明，我們需要一個表空間并將一個或兩個表放入其中，以便觀察“取消刪除”的效果：
SQL> create tablespace testts
2 datafile '/u01/oradata/testts_01.dbf' size 1M;
Tablespace created.
SQL> conn arup/arup
Connected.
SQL> create table test_tab1 (col1 number) tablespace testts
2 /
Table created.
SQL> insert into test_tab1 values (1);
1 row created.
SQL> commit;
Commit complete.
進行備份之后，我們在該表空間中創建另一個表
SQL> create table testtab2 tablespace testts as select * from testtab;
Table created.
在實際刪除表空間之前，讓我向您介紹視圖 TS_PITR_OBJECTS_TO_BE_DROPPED，該視圖顯示表空間中將隨表空間一起刪除的對象：
SQL> desc TS_PITR_OBJECTS_TO_BE_DROPPED
Name Null? Type
----------------------------------------- -------- ----------------------------
OWNER NOT NULL VARCHAR2(30)
NAME NOT NULL VARCHAR2(30)
CREATION_TIME NOT NULL DATE
TABLESPACE_NAME VARCHAR2(30)
VARCHAR2(30)
查看該視圖：
select owner, name, tablespace_name,
to_char(creation_time, 'yyyy-mm-dd:hh34:mi:ss')
from ts_pitr_objects_to_be_dropped
where creation_time > sysdate -1
order by creation_time
/
OWNER NAME
------------------------------ ------------------------------
TABLESPACE_NAME TO_CHAR(CREATION_TI
------------------------------ -------------------
ARUP TEST_TAB1
TESTTS 2010-08-03:15:31:16
ARUP TEST_TAB2
TESTTS 2010-08-03:15:33:09
該視圖顯示了我們之前創建的兩個表。現在，使用 including contents 子句刪除表空間，這也將刪除其中的表。
SQL> drop tablespace testts including contents;
Tablespace dropped.
如果您要查看上述視圖，執行以下命令：
sql> select owner, name, tablespace_name,
2 to_char(creation_time, 'yyyy-mm-dd:hh34:mi:ss')
3 from ts_pitr_objects_to_be_dropped
4 where creation_time > sysdate -1
5* order by creation_time
兩個表將不存在。
現在，您需要取消刪除表空間。要實現這一目的，您必須知道刪除表空間的時間。一種簡單的方法是查看警報日志。下面是警報日志的節選：
Tue Aug 03 15:35:54 2010
drop tablespace testts
ORA-1549 signalled during: drop tablespace testts...
drop tablespace testts including contents
Completed: drop tablespace testts including contents
為將表空間恢復回數據庫中，我們將使用該時間戳，恰好是執行 drop tablespace 命令的時間。
RMAN> recover tablespace testts
2> until time "to_date('08/03/2010 15:35:53','mm/dd/yyyy hh34:mi:ss')"
3> auxiliary destination '/u01/oraux';
其中的 auxiliary destination 是將創建的新數據庫文件的所在位置。在此，您可以使用任何空間，甚至包括計劃用于其他內容的氣泡空間，因為只是臨時需要該空間。（此處為該 RMAN 命令的輸出。）
就是這樣；現在，表空間再次可用。讓我們看一下該命令實際執行的操作：
創建一個名為 Dvlf 的數據庫實例。特意采用這種方式拼寫實例名稱，是為了盡量避免與現有實例名稱沖突。
識別所有包含撤銷段的表空間
還原必需的表空間（包括刪除的表空間、SYSTEM、SYSAUX 以及 UNDO 表空間）
傳輸表空間 testts（刪除的表空間）
將 testts 表空間插入回主數據庫中
當 testts 表空間可用時，它處于脫機模式。您必須使其聯機。
SQL> alter tablespace testts online;
Tablespace altered.
讓我們確保同時獲取正確的數據：
SQL> conn arup/arup
Connected.
SQL> select count(1) from test_tab1;
COUNT(1)
----------
1
按照預期恢復了表 TEST_TAB1；但 TEST_TAB2 怎么樣了呢？
SQL> select count(1) from test_tab2;
COUNT(1)
----------
1
它也得以恢復。它是如何恢復的？該表是備份之后創建的。恢復時應該不包括它啊？
并非如此。表空間恢復會恢復到最后一個可用的重做條目。還原表空間備份并應用存檔日志（以及重做日志），以便與發生故障之前的時刻完全保持一致，因為這是 recovery 子句無法實現的。
現在，如果您要查看上述視圖，執行以下命令：
select owner, name, tablespace_name,
to_char(creation_time, 'yyyy-mm-dd:hh34:mi:ss')
from ts_pitr_objects_to_be_dropped
where creation_time > sysdate -1
order by creation_time
/
OWNER NAME
------------------------------ ------------------------------
TABLESPACE_NAME TO_CHAR(CREATION_TI
------------------------------ -------------------
ARUP TEST_TAB1
TESTTS 2010-08-03:15:31:16
ARUP TEST_TAB2
TESTTS 2010-08-03:15:33:09
就是這樣；現在，表空間已“取消刪除”，并且所有數據均可用。您只需幾行 RMAN 命令即可完成該操作，而不必制定復雜的活動計劃。
該方法的另一個好處是不必非將表空間還原到這個特定的時刻。假設您要將表空間還原到過去某個特定的時間點。可以通過在 until 子句中使用不同的時間來執行該操作；稍后，您可以再將其恢復到另一個時間點。如果需要，這可以重復任意多次。在以前代碼版本中，一旦將表空間恢復到某個時間點，便無法將其恢復到早于該時間點的另一個時間點。
記得在以前的代碼版本中，執行表空間時間點恢復時，必須針對數據文件使用 AUXNAME 參數。這可以讓您恢復表空間，但數據文件名稱不同；因此，必須將表空間插入數據庫中。現在的過程不需要 AUXNAME 參數。但請注意，AUXNAME 并不總是必需的。當數據文件名稱與備份相同時（通常在映像副本的情況下），需要該參數。
假設您從同一服務器或不同服務器（如臨時服務器）的備份中還原數據文件。如果文件系統（或磁盤組）名稱相同，則不必進行任何更改。但很少存在這種情況。在臨時服務器中，文件系統可能不同，或者您將生產數據庫還原到的 ASM 磁盤組并非最初創建數據庫時所用的磁盤組。在這種情況下，您必須讓 RMAN 知道數據文件的新名稱。實現此操作的方法是使用 SET NEWNAME 命令。下面是一個示例，其中已還原的文件位于 /u02 中而不是 /u01 中，/u01 中是以前的代碼版本。
run
{
set newname for datafile 1 to ‘/u02/oradata/system_01.dbf’;
set newname for datafile 2 to ‘/u02/oradata/sysaux_01.dbf’;
restore database; …
}
這里只有兩個數據文件，但是，如果有成百上千數據文件怎么辦呢？輸入所有信息不僅是一項艱巨的任務，而且還容易出錯。現在，您可以針對表空間使用一個 set newname 子句，而不是按名稱輸入每個數據文件。下面是實現該操作的代碼：
run
{
set newname for tablespace examples to '/u02/examples%b.dbf';
…
… rest of the commands come here …
}
如果表空間包含多個數據文件，則所有數據文件均單獨創建。您也可以針對整個數據庫使用該子句：
run
{
set newname for database to '/u02/oradata/%b';
}
%b 項指定不帶路徑的基文件名，例如，/u01/oradata/file1.dbf 在 %b 中將作為 file1.dbf 進行重新代碼發送。當您要將文件移到其他目錄時，這非常有用。您還可以使用該子句創建映像副本，其中您將使用與父文件相同的名稱在其他位置創建備份，這將便于識別。
警告：Oracle 托管文件沒有特定的基名；因此，該項無法用于這些文件。下面是其他一些占位符示例。
%f 是絕對文件號
%U 是系統生成的唯一名稱，類似于備份格式中的 %U
%I 是數據庫 ID
%N 是表空間名稱
使用這些占位符，您可以針對整個數據庫僅使用一個 SET NEWNAME 命令，這樣不僅過程簡單，而且命令更加準確。
當數據庫中的數據塊受損時，您有哪些選擇呢？Oracle9i 代碼的唯一選擇是還原整個數據文件。在 Oracle9i 中，我們也可以使用塊介質恢復特性從備份中修復特定塊，而不是整個數據文件，從而節省大量時間。
Data Recovery Advisor 可以非常清晰地顯示可能受損的塊。但在第 2 版之前，仍需要從備份修復塊。如果備份位于某個較慢的驅動器中，而這通常是因為您可能不希望將備份與數據庫本身放在同一類型的昂貴磁盤中所致，應該怎么辦呢？如果您具有物理備用數據庫（它是數據文件的一個精確副本），并且最可能位于速度較快的存儲中。如果您可以從該數據庫中修復塊，速度將會快得多。
現在，您可以從物理備用數據庫修復塊了。如果您有多個物理備用數據庫，如何知道要從哪些備用數據庫中獲取塊呢？顯然，應該選擇具有最新更新的備用數據庫。RMAN 可通過檢查所有物理備用數據庫來自動建議最適合目標的代碼。當然，在這種情況下，必須打開數據庫以便查詢，這意味著您必須有 Active Data Guard 選件。
您是否熟悉 Oracle 托管文件 (OMF)？它們是由 Oracle 管理的無需您干預的數據文件、日志文件和控制文件。這些文件按名稱整齊地組織在各自的文件夾中，其名稱對于您來說可能并不意味著什么，但對 Oracle 數據庫來說意味著一切。您要么喜歡 OMF，要么討厭它；但不可能介于兩者之間。您有足夠的理由喜歡它 — 不必擔心文件名、位置和相關問題，如名稱沖突。由于位置是通過代碼定義的，例如，對數據文件使用 DATAFILES，對重做日志文件使用 ONLINELOGS 等，因此便于其他工具使用。如果您使用 ASM，則使用 OMF — 您可能對其不甚了解。
您可能希望將同一結構擴展到 RMAN 備份，您只需在其中定義一個位置，將文件放入其中，一切就會組織得整整齊齊。在 Oracle Database 11g 第 2 版中，您可以在 BACKUP 命令中使用一個新子句來指定位置。下面是其使用方法：
RMAN> backup tablespace abcd_data to destination '/u01/oraback';
注意，上述命令中沒有 %U 之類的格式字符串，不同于我們以前使用的備份命令。輸出如下：
Starting backup at 08/09/10 16:42:15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=35 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=+DATA/d112d1/datafile/abcd_data.272.697114011
channel ORA_DISK_1: starting piece 1 at 08/09/10 16:42:17
channel ORA_DISK_1: finished piece 1 at 08/09/10 16:44:22
piece
handle=/u01/oraback/D112D1/backupset/2010_08_09/o1_mf_nnndf_TAG20100809T164216_660t194b_.
bkp tag=TAG20100809T164216 comment=NONE
channel ORA_DISK_1:
backup set complete, elapsed time: 00:02:05
Finished backup at 08/09/10 16:44:22
該子句以有組織的方式創建備份文件。上述命令創建了目錄 D112D1（實例的名稱），在該目錄下創建了一個名為 backupset 的目錄，在 backupset 目錄下又創建另一個以文件創建日期作為名稱的目錄。最后，使用系統生成的標記創建備份內容。當您使用該命令備份存檔日志時，備份內容位于子目錄 archivelogs 下，依此類推。
您還可以在 ALLOCATE CHANNEL 命令中使用該子句：
RMAN> run {
2> allocate channel c1 type disk to destination '/u01/oraback';
3> }
RMAN 中的代碼壓縮并不是什么新東西；它已經應用一段時間了。下面顯示了如何創建表空間 ABCD_DATA 的代碼壓縮備份集。
RMAN> backup as comcodessed backupset
2> format '/u01/oraback/%U.rmb'
3> tablespace abcd_data
4> ;
在 Oracle Database 11g 第 1 版中，我們看到引入了一種名為 ZLIB 的新加密算法，該算法速度很快（占用更少的 CPU），但代碼壓縮率卻降低了。在 Oracle Database 11g 第 2 版中，提供了幾個代碼壓縮選項。
默認的代碼壓縮為基本配置，它不需要任何額外開銷來購買選件。使用 comcodession 的高級選項，您現在能夠指定不同類型的代碼壓縮級別：LOW、MEDIUM 和 HIGH — 代碼壓縮率從最低到最高，CPU 占用（RMAN 吞吐量相反）從最低到最高。下面是將 comcodession 選項配置為 high 的命令：
rman> configure comcodession algorithm 'high';
在測試中，我使用 HIGH 級別獲取代碼壓縮的備份集，代碼壓縮后的字節數為 118947840，與未進行代碼壓縮的字節數 1048952832 相比，空間約為原來的 1/9。當然，壓縮比例視數據庫而不同。
comcodession 選項的設置越高，創建的備份集就越小，這對于速度較慢的網絡很有意義，但占用 CPU 周期。
在本文的結尾，我們將討論 RMAN 目標中一個最令人興奮的高級特性。在當今的云計算時代，有一種超群的功能，那就是備份，因此各企業都轉向基于云的服務提供商而不是在它們自己的硬件方面進行投資。正如其本身所定義的那樣，備份應該是異地備份；而云是最好不過的選擇。Amazon 提供了 Simple Storage Service (S3)，它實質上是一個大型存儲氣泡，可以存儲任意多內容。作為客戶，您只需按實際使用付費。Amazon 負責存儲的可靠性。
Oracle Database 11g 第 2 版附帶了各種工具（庫和軟件），可以使用專門開發的介質管理庫 (MML) 通過 RMAN 將 Oracle 數據庫備份到 Amazon S3。我在此并不介紹這項服務，而是希望您將注意力轉向該服務的分步指南http://download.oracle.com/docs/cd/E11882_01/backup.112/e10643/web_services001.htm#RCMRF90490
該指南寫的非常好，并且包含代碼，在此再介紹該指南是完全多余的。
以上是“Oracle11g備份恢復新特性有哪些”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
