通过RMAN备份恢复数据库到其他服务器

通过RMAN备份恢复数据库到其他服务器
本节演示如何通过RMAN创建的备份集，将数据库恢复到其他服务器。本小节执行的操作较多，一定要有一个清醒的大脑，因此赶紧把脑袋里那堆乱七八糟的东西清除清除，要不你一定会看晕的。
设定环境如下：
源库192.168.0.116 ，SID：crm。
目录库192.168.0.117，已安装与源库相同版本的数据库软件（一定要相同版本哟）。
准备工作如下：
记录下源数据库的DBID，DBID的获取方式上节已讲过。
   SQL> select dbid from v$database;


     DBID
   ----------
   3759797127
   
创建完整备份集（含控制文件、数据文件、归档文件），源库为非归档模式也可以，只要确保创建的备份是一致备份，然后将备份集复制到目标服务器的相同路径下。
为简单起见，源端与目标端目录结构保持一致。如果你在测试或正式操作时由于实际原因无法保持源端与目标端结构一致，在恢复过程中注意修改相关路径。
操作步骤如下：
注意，下列操作如非特别注明，均是在目标端服务器上进行的。
1．在源库端创建数据库的完整备份


RMAN> backup database plus archivelog;




Starting backup at 15-AUG-17
current log archived
using channel ORA_DISK_1
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=23 RECID=20 STAMP=951793319
input archived log thread=1 sequence=24 RECID=21 STAMP=951799464
input archived log thread=1 sequence=25 RECID=22 STAMP=952053252
input archived log thread=1 sequence=26 RECID=23 STAMP=952064952
input archived log thread=1 sequence=27 RECID=24 STAMP=952065088
input archived log thread=1 sequence=28 RECID=25 STAMP=952067283
input archived log thread=1 sequence=29 RECID=26 STAMP=952072390
channel ORA_DISK_1: starting piece 1 at 15-AUG-17
channel ORA_DISK_1: finished piece 1 at 15-AUG-17
piece handle=/data/arch/flashcovery/CRM/backupset/2017_08_15/o1_mf_annnn_TAG20170815T083311_ds5tj8py_.bkp tag=TAG20170815T083311 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:26
Finished backup at 15-AUG-17


Starting backup at 15-AUG-17
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/opt/oracle/oradata/crm/system01.dbf
input datafile file number=00002 name=/opt/oracle/oradata/crm/sysaux01.dbf
input datafile file number=00003 name=/opt/oracle/oradata/crm/undotbs01.dbf
input datafile file number=00004 name=/opt/oracle/oradata/crm/users01.dbf
channel ORA_DISK_1: starting piece 1 at 15-AUG-17
channel ORA_DISK_1: finished piece 1 at 15-AUG-17
piece handle=/data/arch/flashcovery/CRM/backupset/2017_08_15/o1_mf_nnndf_TAG20170815T083338_ds5tk2vo_.bkp tag=TAG20170815T083338 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:04:56
Finished backup at 15-AUG-17


Starting backup at 15-AUG-17
current log archived
using channel ORA_DISK_1
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=30 RECID=27 STAMP=952072714
channel ORA_DISK_1: starting piece 1 at 15-AUG-17
channel ORA_DISK_1: finished piece 1 at 15-AUG-17
piece handle=/data/arch/flashcovery/CRM/backupset/2017_08_15/o1_mf_annnn_TAG20170815T083835_ds5ttcd3_.bkp tag=TAG20170815T083835 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 15-AUG-17


Starting Control File and SPFILE Autobackup at 15-AUG-17
piece handle=/data/arch/flashcovery/CRM/autobackup/2017_08_15/o1_mf_s_952072716_ds5ttfqz_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 15-AUG-17


备份集创建成功之后，将其复制到目录端的相同路径下，强调一点，必须是相同路径。复制方式灵活多样，Windows环境可以直接通过共享复制，Linux/UNIX下可以通过FTP。
scp -r /data/arch/flashcovery/CRM/backupset/2017_08_15/* oracle@192.168.0.117:/data/arch/flashcovery/CRM/backupset/2017_08_15/
scp /data/arch/flashcovery/CRM/autobackup/2017_08_15/*.bkp oracle@192.168.0.117:/data/arch/flashcovery/CRM/autobackup/2017_08_15/
2．在目标服务器上创建OracleService
如果是Linux/UNIX环境，不需要执行本步骤，只要在连接数据库时指定ORACLE_SID环境变量即可。




3．配置目标端数据库的初始化参数文件
这个配置主要包括两步：
第一步是将源库端的SPFILE初始化参数文件复制到目标端的适当路径，即%ORACLE_HOME%\database目录下，如果是Linux/UNIX环境则是在$ORACLE_HOME\dbs目录下。
[oracle@siedb dbs]$ scp spfilecrm.ora oracle@192.168.0.117:/opt/oracle/product/11g/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命令行环境：


根据源库复制过来的SPFILE创建PFILE，注意给PFILE指定适当的路径，执行命令如下：
SQL> create pfile from spfile;
File created. 
如果从源库复制出来的SPFILE并没放在%ORACLE_HOME%\DATABASE目录下，也可以通过FROM SPFILE=''的方式指定SPFILE的详细路径，例如：


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命令行：
[oracle@siedb2 data]$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Tue Aug 15 10:52:01 2017
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
connected to target database: CRM (not mounted)
RMAN>
由于此时目标数据库尚无控制文件，因此此处必须首先指定DBID：


RMAN> set dbid=3759797127;


executing command: SET DBID


从指定备份集中恢复控制文件：


1. RMAN> restore controlfile from '/data/arch/flashcovery/CRM/autobackup/2017_08_15/o1_mf_s_952072716_ds5ttfqz_.bkp';
Starting restore at 15-AUG-17
using channel ORA_DISK_1


channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/opt/oracle/oradata/crm/control01.ctl
output file name=/data/arch/flashcovery/crm/control02.ctl
Finished restore at 15-AUG-17


控制文件会被恢复到初始化参数CONTROL_FILES指定的路径下。
有了控制文件，就可以将数据库置为MOUNT状态了：
RMAN> alter database mount;


database mounted
released channel: ORA_DISK_1


5．修复数据库
在这个测试环境中，源端与目标端的路径保持一致，因此这里可以直接用源路径修复，如果你的目标库与源库路径不同的话，需要通过SET NEWNAME FOR DATAFILE命令来为数据文件重新设定路径（注意，SET NEWNAME必须要放在RUN块中执行的哟）。执行命令如下：


RMAN> restore database;


Starting restore at 15-AUG-17
Starting implicit crosscheck backup at 15-AUG-17
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK
Crosschecked 18 objects
Finished implicit crosscheck backup at 15-AUG-17


Starting implicit crosscheck copy at 15-AUG-17
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 15-AUG-17


searching for all files in the recovery area
cataloging files...
cataloging done


List of Cataloged Files
=======================
File Name: /data/arch/flashcovery/CRM/autobackup/2017_08_15/o1_mf_s_952072716_ds5ttfqz_.bkp
File Name: /data/arch/flashcovery/CRM/backupset/2017_08_08/o1_mf_nnndf_TAG20170808T102227_drml9466_.bkp
File Name: /data/arch/flashcovery/CRM/backupset/2017_08_08/o1_mf_ncsnf_TAG20170808T102227_drmlf6dn_.bkp
File Name: /data/arch/flashcovery/CRM/archivelog/2017_08_08/o1_mf_1_16_drml674b_.arc


using channel ORA_DISK_1


channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /opt/oracle/oradata/crm/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /opt/oracle/oradata/crm/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /opt/oracle/oradata/crm/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /opt/oracle/oradata/crm/users01.dbf
channel ORA_DISK_1: reading from backup piece /data/arch/flashcovery/CRM/backupset/2017_08_15/o1_mf_nnndf_TAG20170815T083338_ds5tk2vo_.bkp
channel ORA_DISK_1: piece handle=/data/arch/flashcovery/CRM/backupset/2017_08_15/o1_mf_nnndf_TAG20170815T083338_ds5tk2vo_.bkp tag=TAG20170815T083338
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:38
Finished restore at 15-AUG-17




觉着神奇是吧，这样都可以，不需要指定备份集位置吗？有这样的疑问说明你独立思考得还不够多啊，虽然说人类一思考上帝就发笑，但是作为一名勤劳、勇敢、朴实（就是不爱思考）的中国人，上帝并不是我们的主要信仰，它也管不了神奇的东方世界这嘎。
应该说，在一般情况下执行本操作时，不需要做特别的设置，前面在备份章节曾经说过，在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号或时间，执行不完全恢复。当然，我们现在执行的也是不完全恢复。


把源端redolog复制到目标端相应目录后，再进行recover,就不报错了
[oracle@siedb crm]$ scp redo0*.log oracle@192.168.0.117:/opt/oracle/oradata/crm/
oracle@192.168.0.117's password: 
redo01.log                                                                     100%   50MB   1.4MB/s   00:37    
redo02.log                                                                     100%   50MB   1.6MB/s   00:32    
redo03.log                                                                     100%   50MB   1.4MB/s   00:37 


RMAN> recover database;


Starting recover at 15-AUG-17
using channel ORA_DISK_1


starting media recovery


archived log for thread 1 with sequence 30 is already on disk as file /opt/oracle/oradata/crm/redo03.log
archived log for thread 1 with sequence 31 is already on disk as file /opt/oracle/oradata/crm/redo01.log
archived log file name=/opt/oracle/oradata/crm/redo03.log thread=1 sequence=30
archived log file name=/opt/oracle/oradata/crm/redo01.log thread=1 sequence=31
media recovery complete, elapsed time: 00:00:07
Finished recover at 15-AUG-17






7．用OPEN RESETLOGS方式打开数据库
最后，以OPEN RESETLOGS方式打开数据库即可：


RMAN> alter database open resetlogs;


database opened
至此，数据库在192.168.0.117服务器端创建成功。