通過RMAN備份恢復資料庫到其他伺服器
本節演示如何通過RMAN建立的備份集，將資料庫恢復到其他伺服器。本小節執行的操作較多，一定要有一個清醒的大腦，因此趕緊把腦袋裡那堆亂七八糟的東西清除清除，要不你一定會看暈的。
設定環境如下：
源庫192.168.100.100，SID：jssbook。
目錄庫192.168.100.101，已安裝與源庫相同版本的資料庫軟體（一定要相同版本喲）。
準備工作如下：
記錄下源資料庫的DBID，DBID的獲取方式上節已講過。
建立完整備份集（含控制檔案、資料檔案、歸檔檔案），源庫為非歸檔模式也可以，只要確保建立的備份是一致備份，然後將備份集複製到目標伺服器的相同路徑下。
為簡單起見，源端與目標端目錄結構保持一致。如果你在測試或正式操作時由於實際原因無法保持源端與目標端結構一致，在恢復過程中注意修改相關路徑。
操作步驟如下：
注意，下列操作如非特別註明，均是在目標端伺服器上進行的。
1．在源庫端建立資料庫的完整備份
這個過程不用演示了，請沒自信的同學自覺重溫第8章。
備份集建立成功之後，將其複製到目錄端的相同路徑下，強調一點，必須是相同路徑。複製方式靈活多樣，Windows環境可以直接通過共享複製，Linux/UNIX下可以通過FTP。
2．在目標伺服器上建立OracleService
如果是Linux/UNIX環境，不需要執行本步驟，只要在連線資料庫時指定ORACLE_SID環境變數即可。
如果是Windows伺服器，需要通過ORADIM命令建立一個OracleService，建立的SID要與源庫相同，操作如下：
1. C:/Documents and Settings/Administrator>ORADIM -NEW -SID JSSBOOK
2. Instance created.
上述命令建立了一個名為jssbook的OracleService。
關於ORADIM命令的引數說明，直接執行ORADIM命令，不加任何引數即可看到簡要說明。
3．配置目標端資料庫的初始化引數檔案
這個配置主要包括兩步：
第一步是將源庫端的SPFILE初始化引數檔案複製到目標端的適當路徑，即%ORACLE_HOME%/database目錄下，如果是Linux/UNIX環境則是在$ORACLE_HOME/dbs目錄下。
第二步是要修改其中的部分引數值，這一步並不是必須的，如果目標端的路徑與源端保持完全一致，不做任何修改都可以。不過如果路徑不一致的話，至少要保證如下幾個引數所指定的值正確有效：
control_files：控制檔案路徑。
audit_file_dest：Oracle審計輸出的debug日誌路徑。
background_dump_dest：LGWR、DBWn之類後臺程序輸出的debug日誌路徑。
core_dump_dest：Oracle核心輸出的dump日誌路徑。
user_dump_dest：使用者程序輸出的debug日誌路徑。
log_archive_dest_1：歸檔檔案路徑，如果啟用了歸檔模式的話。
由於SPFILE是二進位制檔案，無法直接編輯，如果要修改，可以先通過SPFILE建立PFILE（客戶端初始化引數檔案），PFILE可以用文字編輯工具開啟（如"記事本"），修改完相關引數值後，再通過PFILE建立SPFILE即可，大致步驟如下：
指定ORACLE_SID，然後連線到SQL*Plus命令列環境：
1. C:/Documents and Settings/Administrator>set oracle_sid=jssbook
2. C:/Documents and Settings/Administrator>sqlplus "/ as sysdba"
3. SQL*Plus: Release 10.2.0.1.0 - Production on Tue May 5 13:16:59 2009
4. Copyright (c) 1982, 2005, Oracle. All rights reserved.
5. Connected to an idle instance.
根據源庫複製過來的SPFILE建立PFILE，注意給PFILE指定適當的路徑，執行命令如下：
1. SQL> CREATE PFILE = 'f:/oracle/backup/pfile_jssbook.ora'
2. FROM SPFILE;File created.
如果從源庫複製出來的SPFILE並沒放在%ORACLE_HOME%/DATABASE目錄下，也可以通過FROM SPFILE=''的方式指定SPFILE的詳細路徑，例如：
1. SQL> CREATE PFILE = 'f:/oracle/backup/pfile_jssbook.ora'
2. FROM SPFILE='f:/oracle/product/10.2.0/db_1/database/ spfilejssbook.ora';
使用"記事本"之類的文字工具開啟檔案F:/oracle/backup/pfile_jssbook.ora，修改相關引數值並儲存。
返回SQL*Plus命令列環境，執行下列命令，根據修改過的PFILE建立SPFILE：
1. SQL> CREATE SPFILE From Pfile='f:/oracle/backup/pfile_jssbook.ora';
2. File created.
SPFILE建立成功，資料庫就可以啟動到NOMOUNT狀態了。
1. SQL> STARTUP NOMOUNT
2. ORACLE instance started.
3. Total System Global Area 314572800 bytes
4. Fixed Size 1248720 bytes
5. Variable Size 67109424 bytes
6. Database Buffers 239075328 bytes
7. Redo Buffers 7139328 bytes
4． 恢復控制檔案並進入到載入狀態
新開一個命令列視窗，連線到RMAN命令列：
1. C:/Documents and Settings/junsansi>SET ORACLE_SID=jssbook
2. C:/Documents and Settings/junsansi>RMAN TARGET /
3. Recovery Manager: Release 10.2.0.1.0 - Production on
4. Tue May 5 13:54:15 2009
5. Copyright (c) 1982, 2005, Oracle. All rights reserved.
6. connected to target database: jssbook (not mounted)
由於此時目標資料庫尚無控制檔案，因此此處必須首先指定DBID：
1. RMAN> SET DBID=1415261003
2. executing command: SET DBID
從指定備份集中恢復控制檔案：
1. RMAN> RESTORE CONTROLFILE FROM 'F:/oracle/backup/
2. C-1415261003-20090505-00';
3. Starting restore at 05-MAY-09
4. using target database control file instead of recovery catalog
5. allocated channel: ORA_DISK_1
6. channel ORA_DISK_1: sid=157 devtype=DISK
7. channel ORA_DISK_1: restoring control file
8. channel ORA_DISK_1: restore complete, elapsed time: 00:00:04
9. output filename=F:/ORACLE/ORADATA/JSSBOOK/CONTROL01.CTL
10. output filename=F:/ORACLE/ORADATA/JSSBOOK/CONTROL02.CTL
11. output filename=F:/ORACLE/ORADATA/JSSBOOK/CONTROL03.CTL
12. Finished restore at 05-MAY-09
控制檔案會被恢復到初始化引數CONTROL_FILES指定的路徑下。
有了控制檔案，就可以將資料庫置為MOUNT狀態了：
1. RMAN> ALTER DATABASE MOUNT;
2. database mounted
3. released channel: ORA_DISK_1
5．修復資料庫
在這個測試環境中，源端與目標端的路徑保持一致，因此這裡可以直接用源路徑修復，如果你的目標庫與源庫路徑不同的話，需要通過SET NEWNAME FOR DATAFILE命令來為資料檔案重新設定路徑（注意，SET NEWNAME必須要放在RUN塊中執行的喲）。執行命令如下：
1. RMAN> RESTORE DATABASE;
2. Starting restore at 05-MAY-09
3. allocated channel: ORA_DISK_1
4. channel ORA_DISK_1: sid=157 devtype=DISK
5. channel ORA_DISK_1: starting datafile backupset restore
6. channel ORA_DISK_1: specifying datafile(s) to restore from backup set
7. restoring datafile 00001 to F:/ORACLE/ORADATA/JSSBOOK/SYSTEM01.DBF
8. restoring datafile 00002 to F:/ORACLE/ORADATA/JSSBOOK/UNDOTBS01.DBF
9. restoring datafile 00003 to F:/ORACLE/ORADATA/JSSBOOK/SYSAUX01.DBF
10. restoring datafile 00004 to F:/ORACLE/ORADATA/JSSBOOK/USERS01.DBF
11. restoring datafile 00005 to F:/ORACLE/ORADATA/JSSBOOK/SCOTT_TBS01.DBF
12. restoring datafile 00006 to F:/ORACLE/ORADATA/JSSBOOK/BOOKS01.DBF
13. channel ORA_DISK_1: reading from backup piece
14. F:/ORACLE/BACKUP/BAK_1JKE921J_1_1
15. channel ORA_DISK_1: restored backup piece 1
16. piece handle=F:/ORACLE/BACKUP/BAK_1JKE921J_1_1 tag=TAG20090505T134835
17. channel ORA_DISK_1: restore complete, elapsed time: 00:00:55
18. Finished restore at 05-MAY-09
覺著神奇是吧，這樣都可以，不需要指定備份集位置嗎？有這樣的疑問說明你獨立思考得還不夠多啊，雖然說人類一思考上帝就發笑，但是作為一名勤勞、勇敢、樸實（就是不愛思考）的中國人，上帝並不是我們的主要信仰，它也管不了神奇的東方世界這嘎。
應該說，在一般情況下執行本操作時，不需要做特別的設定，前面在備份章節曾經說過，在NOCATALOG模式下，備份集資訊是儲存在控制檔案中的，現在控制檔案已經恢復了，它當然知道應該上哪兒找備份集。
那什麼時候需要手動指定備份集呢？只有一種情況，當你的備份集不在控制檔案的原路徑時，你必須通過CATALOG命令重新註冊備份集，也就是告訴RMAN，它要找的備份集在哪裡。
6．恢復資料庫
RECOVER也是同理，不需要你告訴他歸檔在什麼位置，它也知道上哪去找，因為控制檔案裡都記著呢，直接執行RECOVER即可：
1. RMAN> RECOVER DATABASE;
2. Starting recover at 05-MAY-09
3. using channel ORA_DISK_1
4. starting media recovery
5. channel ORA_DISK_1: starting archive log restore
6. to default destination
7. channel ORA_DISK_1: restoring archive log
8. archive log thread=1 sequence=51
9. channel ORA_DISK_1: reading from backup piece
10. F:/ORACLE/BACKUP/BAK_1KKE923B_1_1
11. channel ORA_DISK_1: restored backup piece 1
12. piece handle=F:/ORACLE/BACKUP/BAK_1KKE923B_1_1
13. tag=TAG20090505T134931
14. channel ORA_DISK_1: restore complete,
15. elapsed time: 00:00:01
16. archive log filename=F:/ORACLE/ORADATA/JSSBOOK
17. /ARCHIVE/ARC00051_0680477835.001 thread=1 sequence=51
18. unable to find archive log
19. archive log thread=1 sequence=52
20. RMAN-00571: ===========================================================
21. RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
22. RMAN-00571: ===========================================================
23. RMAN-03002: failure of recover command at 05/05/2009 14:04:38
24. RMAN-06054: media recovery requesting unknown log:
25. thread 1 seq 52 lowscn 983415
報錯了？正常的，因為我們建立的熱備份並不是一致性備份，源端的歸檔是過來了，但聯機重做日誌檔案並沒有隨備份集複製過來，因此恢復時肯定恢復不到源端的當前狀態。這個錯誤是提醒你要想繼續恢復的話還需要執行緒1生成的SEQUENCE#為52的重做日誌檔案。我們這裡只是測試恢復到異機的過程，並不準備保持與源資料庫端一模一樣（如果你要保持一致，必須複製源資料庫端的重做日誌檔案，那必須首先SHUTDOWN源端資料庫才行）。
如果說你只是希望避免看到這個錯誤，可以在RECOVER DATABASE前指定SET UNTIL SCN或者用SET UNTIL TIME命令設定恢復到的SCN號或時間，執行不完全恢復。當然，我們現在執行的也是不完全恢復。
7．用OPEN RESETLOGS方式開啟資料庫
最後，以OPEN RESETLOGS方式開啟資料庫即可：
1. RMAN> ALTER DATABASE OPEN RESETLOGS;
2. database opened
至此，資料庫在192.168.100.101伺服器端建立成功。