【RMAN】Oracle11g備份恢復新特性

xysoul_雲龍發表於2017-07-25

閃回日誌急救

還記得 Oracle Database 10g 中引入的閃回日誌記錄嗎?如果資料庫中已啟用了閃回功能,閃回日誌會將更改塊的以前映像的最佳化版本記錄到在閃回恢復區生成的閃回日誌中。這些日誌可以幫助您將資料庫閃回到過去的一個時間點,而不必從備份中執行時間點恢復。

那麼,既然這些閃回日誌包含塊的以前的映像,為什麼不將它們也用於恢復呢?Oracle Database 11g 正是這麼做的。當您恢復特定的塊時,Oracle 會在閃回日誌(而不是資料檔案)中查詢該塊的以前映像的良好副本,然後應用存檔日誌以使其向前滾動。由於無需藉助備份,該方法可以節省很多時間,尤其是當備份在磁帶上時。

ZLIB 壓縮

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 中取消註冊,同時又在新的目錄中進行了註冊。

 

從備份中複製資料庫(僅限第 2 版)

您由於各種原因需要複製資料庫,例如搭建 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 hh24: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”。

取消刪除表空間(僅限第 2 版)

比如說您要清理資料庫中的垃圾,於是希望刪除可能早已不存在的使用者建立的所有小型和大型表空間。刪除這些表空間時,您不經意地刪除了一個非常關鍵的表空間。該怎麼辦?

在以前程式碼版本中,可選方案是減少表空間總數。下面是執行步驟:

  • 建立另一個名為 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:hh24: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:hh24: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 hh24: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:hh24: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 並不總是必需的。當資料檔名稱與備份相同時(通常在映像副本的情況下),需要該引數。

Set NEWNAME 命令的靈活性(僅限第 2 版)

假設您從同一伺服器或不同伺服器(如臨時伺服器)的備份中還原資料檔案。如果檔案系統(或磁碟組)名稱相同,則不必進行任何更改。但很少存在這種情況。在臨時伺服器中,檔案系統可能不同,或者您將生產資料庫還原到的 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 命令,這樣不僅過程簡單,而且命令更加準確。

自動塊修復(僅限第 2 版)

當資料庫中的資料塊受損時,您有哪些選擇呢?Oracle9i 程式碼的唯一選擇是還原整個資料檔案。在 Oracle9i 中,我們也可以使用塊介質恢復特性從備份中修復特定塊,而不是整個資料檔案,從而節省大量時間。

Data Recovery Advisor 可以非常清晰地顯示可能受損的塊。但在第 2 版之前,仍需要從備份修復塊。如果備份位於某個較慢的驅動器中,而這通常是因為您可能不希望將備份與資料庫本身放在同一型別的昂貴磁碟中所致,應該怎麼辦呢?如果您具有物理備用資料庫(它是資料檔案的一個精確副本),並且最可能位於速度較快的儲存中。如果您可以從該資料庫中修復塊,速度將會快得多。

現在,您可以從物理備用資料庫修復塊了。如果您有多個物理備用資料庫,如何知道要從哪些備用資料庫中獲取塊呢?顯然,應該選擇具有最新更新的備用資料庫。RMAN 可透過檢查所有物理備用資料庫來自動建議最適合目標的程式碼。當然,在這種情況下,必須開啟資料庫以便查詢,這意味著您必須有 Active Data Guard 選件。

TO DESTINATION 子句(僅限第 2 版)

您是否熟悉 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> }


更多程式碼壓縮選擇(僅限第 2 版)

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 週期。

備份到雲(僅限第 2 版)

在本文的結尾,我們將討論 RMAN 目標中一個最令人興奮的高階特性。在當今的雲端計算時代,有一種超群的功能,那就是備份,因此各企業都轉向基於雲的服務提供商而不是在它們自己的硬體方面進行投資。正如其本身所定義的那樣,備份應該是異地備份;而云是最好不過的選擇。Amazon 提供了 Simple Storage Service (S3),它實質上是一個大型儲存氣泡,可以儲存任意多內容。作為客戶,您只需按實際使用付費。Amazon 負責儲存的可靠性。

Oracle Database 11g 第 2 版附帶了各種工具(庫和軟體),可以使用專門開發的介質管理庫 (MML) 透過 RMAN 將 Oracle 資料庫備份到 Amazon S3。我在此並不介紹這項服務,而是希望您將注意力轉向該服務的分步指南

該指南寫的非常好,並且包含程式碼,在此再介紹該指南是完全多餘的。

作者:Arup Nanda



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29487349/viewspace-2142533/,如需轉載,請註明出處,否則將追究法律責任。

相關文章