rman全库恢复到不同主机，不同实例名，不同目录下

Posted 2020-08-16 梦想是用来坚持的！

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了rman全库恢复到不同主机，不同实例名，不同目录下相关的知识，希望对你有一定的参考价值。

一、配置目标主机的ip、hostname及与源端主机的连通性

1、配置目标主机IP

使用图形界面配置IP：

administration----network---修改IP(指定静态IP)

deactivate网卡---activate网卡（重启网卡配置才能生效）
或者使用root用户执行：service network restart 重启网卡

2、配置主机名

root用户执行：hostname hostNameValue
vi /etc/sysconfig/network

修改：HOSTNAME=edsir4p1.us.oracle.com

修改/etc/hosts文件中IP到主机名的映射

127.0.0.1 localhost.localdomain localhost

192.168.33.138 edsir4p1.us.oracle.com edsir4p1

192.168.33.137 edsir1p8.us.oracle.com edsir1p8

3、测试到源端主机的连通性

ping edsir1p8.us.oracle.com

或者

ping 192.168.33.137

【漫兮网（http://www.manxinet.com）】

二、规划目标机上备份集的保存路径

因为控制文件中记录的备份集的保存路径是记录的备份集在源端（edsir1p8）主机上的路径，如果scp到目标主机后和原来备份集的保存路径不一致，那么控制文件中记录的所有的备份集的元数据信息都将失效，必须执行：catalog start with ‘/backupset_path‘

让控制文件自动识别备份集的元数据信息（路径、备份片名等）。

现在在目标端设置备份集的存储路径和源端一致，这样就避免了需要控制文件自动识别备份集元数据的过程，避免备份集识别不完全（漏掉备份片）

目标端备份集规划路径如下：

full备份：

database：/u01/app/oracle/oradata/backupset/prod4/full/database

controlfile: /u01/app/oracle/oradata/backupset/prod4/full/controlfile

arch : /u01/app/oracle/oradata/backupset/prod4/full/arch

controfile备份：

controlfile：/u01/app/oracle/oradata/backupset/prod4/controlfile

arch备份：

arch ：/u01/app/oracle/oradata/backupset/prod4/arch

自动备份控制文件和spfile：

controlfile+spfile：

/u01/app/oracle/oradata/autobackup/prod4

三、规格恢复后数据库的数据文件保存路径

恢复的新instance名为：CPROD4

全库恢复后的数据文件保存路径：

datafile：/u01/app/oracle/oradata/CPROD4/datafile

redo ：/u01/app/oracle/oradata/CPROD4/onlinelog

tempfile：/u01/app/oracle/oradata/CPROD4/tempfile

controlfile：/u01/app/oracle/oradata/CPROD4/controlfile

arch ：/u01/app/oracle/oradata/CPROD4/arch

【漫兮网（http://www.manxinet.com）】

四、全库恢复

1、在源端数据库做全库备份和归档备份

（实际试验前要清空所有备份集delete backup ,但生产上严禁执行该操作）

a.全库备份，在edsir1p8上执行脚本：rman_prod4_full_01.sh

b.归档备份，在edsir1p8上执行脚本：rman_prod4_arch_01.sh

c.备份完成后要查看是否在备份期间生成了新的归档日志。

注：如果在备份期间生成了新的归档日志，并且已经写入到了控制文件的

v$archived_log视图中，但是在备份归档时却没有备份，然后在控制文件自动备份时将当前控制文件备份了，即备份的控制文件中记录了没有备份的归档日志，这样再后续确定恢复截至到的scn号时就会报错，找不到对应的归档日志（备份期间产生的归档日志没有被备份走）

所以在后续确定恢复截至到的scn号时一定要先确定备份集中是否有对应SCN 号的归档日志，不能仅通过v$archived_log视图就简单的确定恢复截至SCN

2、scp或其他方式导入到目标主机

a.传输数据文件

进入到源端edsir1p8的/u01/app/oracle/oradata/backupset/prod4/full/database 目录下

scp * 192.168.33.138: /u01/app/oracle/oradata/backupset/prod4/full/database

b.传输全备的归档：

进入到源端edsir1p8的/u01/app/oracle/oradata/backupset/prod4/full/arch

scp * 192.168.33.138: /u01/app/oracle/oradata/backupset/prod4/full/arch

c.后续传输所有备份集：full备份的控制文件、归档日志、单独备份的控制文件、自动备份的控制文件

注：scp时的“*”表示传输当前路径下的所有文件到目标端

3、spfile文件的恢复

a.使用rman自带的参数文件启动到nomount状态

（i）在138上切换环境变量目的是切换到正确的ORACLE_HOME下可以使用 bin目录下的rman

. oraenv

ORACLE_SID=PROD1

（ii）设置ORACLE_SID恢复该SID对应的spfile文件：spfileSID.ora

export ORACLE_SID=CPROD4

（iii）启动rman到nomount状态

rman target /

RMAN > startup nomount

b.恢复spfile

（i）restore spfile文件

RMAN > restore spfile from

‘/u01/app/oracle/oradata/autobackup/prod4/ctl_c-1612213667-20160305-05‘; 执行过程中会报如下错误：

错误一截图：

reason：源端数据库开启了share mode模式的连接，修改了spfile中的六个参数，现在使用spfile时检测spfile中保存的系统参数发现在目标端没有，因此报以上错误。

PROD4_1526是shared模式的访问连接。并且注册到了local_listener上，但是在目标端138上没有对应的监听和tns别名，需要创建

solution：

从137上复制如下监听内容到138的listener.ora文件中

SID_LIST_PROD4_1526 =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = PROD4.us.oracle.com)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)

(SID_NAME = CPROD4)

)

PROD4_1526 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = edsir4p1.us.oracle.com)(PORT = 1526))

)

ADR_BASE_PROD4_1526 = /u01/app/oracle

从137上复制如下TNS别名内容到138的tnsnames.ora文件中

PROD4_1526 =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = edsir4p1.us.oracle.com)(PORT = 1526))

)

(CONNECT_DATA =

(SERVER = SHARED)

(SERVICE_NAME = PROD4.us.oracle.com)

)

错误二截图：

再次试图打开数据库到nomount状态:

SQL > startup nomouont

会报以上错误

reason：

源端137上开启了数据库审计功能需要创建audit目录，但是138上没有对应的audit目录

solution：

在137上查看参数：show parameter audit

audit_file_dest string /u01/app/oracle/admin/PROD4/adump

在138上创建该目录：mkdir -p /u01/app/oracle/admin/PROD4/adump

或者：

在目标端138上如果数据库能启动到nomount状态，可以在138端查看参数

audit_file_dest，然后创建该目录

c.使用恢复的spfile重新打开数据库到nomount状态

shutdown immediate

startup nomount

4、controlfile文件的恢复

a.先修改controlfile文件的路径

因为在137上controlfile是存储在+DATA磁盘组上的，138上没有ASM实例，故不能成功restore controlfile。

执行如下指令：

alter system set control_files=‘ /u01/app/oracle/oradata/CPROD4/controlfile/ control01.ctl‘ scope=spfile;

重启数据库，重新加载spfile：

shutdown immediate

startup nomount

b.controlfile的恢复

restore controlfile from

‘/u01/app/oracle/oradata/autobackup/prod4/ctl_c-1612213667-20160305-05‘;

修改数据库到mount状态

RMAN > alter database mount;

5、database的恢复

a.确定能恢复到的最大SCN号

(i)从v$archived_log视图中查询最后一个归档的结束SCN值

select name,RESETLOGS_CHANGE#,RESETLOGS_ID,FIRST_CHANGE#,NEXT_CHANGE# from v$archived_log;

截图中是恢复后新产生的归档日志，不是原来恢复前控制文件中记录的归档日志的信息。

原来控制文件中记录的归档的最后一个scn值为：2460383

(ii)在备份集中确认真正存在对应该SCN值的备份片

list backup of archivelog all;

在对应路径

/u01/app/oracle/oradata/backupset/prod4/arch/arch_PROD4_905667093_729_1.bak下确认备份片是否真正存储（注意是确认scp的过程中是否把备份片正确的传输过来了）

同时在显示的备份集列表上观察相关的归档日志备份是否连续。

(iii)在备份片确认真正存在的情况下，再次确认incarnation的值，目的是确认在recover的过程中是否会去一直追加2460383归档对应的resetlog_scn的该批的归档日志

从v$archived_log视图中查询2460383归档对应的RESETLOGS_CHANGE#列值为：2167043

从rman中： RMAN > list incarnation

1 1 PROD4 1612213667 CURRENT 2167043 02-MAR-16

结果显示当前的incarnation对应的Reset SCN的值为2167043

incarnation. Reset SCN =v$archived_log.maxSCN. RESETLOGS_CHANGE#

满足以上条件就说明：在recover的过程中会去寻找和最大SCN对应相同的 RESETLOGS_CHANGE#值的那一批归档日志，直到追加完最大SCN号的归档日志。
如果不满足以上条件说明：在recover的过程中不会去寻找和最大SCN号的归档日志的

RESETLOGS_CHANGE#列值对应相等的那一批归档。这时候如果是简单为了搭建测试环境不考虑丢失数据的多少，可以在v$archived_log视图中寻找合适的SCN值，直到可以追平v$datafile_header视图中的所有文件头的CHECKPOINT_CHANGE#，这样就可以 resetlogs打开数据库

如果考虑到尽可能的少丢失数据就需要设置当前的incarnation值使得满足条件：

incarnation. Reset SCN =v$archived_log.maxSCN. RESETLOGS_CHANGE#

这样就可以在recover的过程中一直追加所有归档，直到追加完最大SCN值对应的归档日志。这也是全库恢复时丢失数据尽可能少的解决办法。这样设置可以恢复到丢失最少数据的状态。（丢失的只有redo中的数据）

b.关闭数据库闪回功能

在源端137上开启了数据库闪回功能：

因为开始数据库闪回时的闪回日志存储路径在：+FLASHBACK磁盘组上

并且开启数据库闪回后resetlogs时重新生成的redo要默认放在和闪回日志相同的路径下，因此要提前校验+FLASHBACK磁盘组，并且在执行restore database时也要校验数据库闪回

在138端没有ASM实例，并且也没有+FLASHBACK磁盘组，因此在后续的执行restore database时就会报错，所以需要在138上关闭数据库闪回功能，并重启数据库重新加载spfile和controlfile

执行如下操作：

138上关闭数据库闪回：

alter database flashback off;

确认关闭是否成功：

select name ,FLASHBACK_ON from v$database;

关闭数据库：

shutdown immediate

重新加载spfile和controlfile

startup mount

因为数据库闪回引起的报错截图如下：

c.修改归档路径

因为137上的归档路径为+ARCH磁盘组

在138上没有ASM实例更没有+ARCH磁盘组，所以在recover的过程中会报错，截图如下：

报错信息显示没有起始SCN为2443916和2427335的归档日志。

排除过程如下：

RMAN > list backup of archivelog all

查过所以归档备份集，找到包含该起始SCN的备份片，首先确认在rman的catalog中是否有这个两个归档的备份片及元数据信息

通过Low SCN和 Next SCN值确定是否有该归档日志的备份片

然后在对应路径下确认该文件是否存在

如果不存在说明scp 的过程中出错：需要重新scp

如果在list backup of archivelog all的显示结果中没有找到，可能的原因是没有注册到rman上，需要重新把归档备份集的路径再注册一次到rman中：

catalog start with ‘ /u01/app/oracle/oradata/backupset/prod4/arch‘

catalog start with ‘ /u01/app/oracle/oradata/backupset/prod4/full/arch‘

如果在list backup of archivelog all的显示结果中有对应的备份片，并且在指定路径下确实存在该备份片文件。那么可能的原因就是源端137上的归档路径在138上没有创建，即138上没有源端的归档日志存放路径。

因为在执行recover的过程中，追加日志的执行过程是这样的：

@先把归档日志备份集释放到控制文件中记录的归档日志存放路径

137上是+ARCH磁盘组，所以在138上会寻找释放存在+ARCH磁盘组

@将所有归档备份集释放到归档日志存放路径下，释放成归档日志文件

@recover过程中读取该路径下的归档日志文件

综上所述：必须在目标端创建和源端相同的路径的归档日志存放目录，或者重新指定归档日志存放路径

因为137端归档日志路径为+ARCH磁盘组

138上没有ASM实例，必须重新指定归档路径

执行如下操作：

查看控制文件中记录的归档路径：

show parameter archive

修改归档路径：

alter system set log_archive_dest_1=‘location=/u01/app/oracle/oradata/CPROD4/arch‘

一致性关闭数据库

shutdown immediate

重新加载spfile和controlfile

startup mount

b.执行恢复脚本

(i) 先查询出控制文件中记录的所有的数据文件信息

select name from v$datafile;

(ii)修改restore的数据文件存储新路径，即恢复到不同的目录下

set newname for datafile ‘+DATA/prod4/datafile/system.286.905335925‘ to ‘/u01/app/oracle/oradata/PROD4_T/datafile/system‘;

(iii)执行restore database;

把数据文件备份集释放到对应的新存储目录下，并重新命名成新的指定文件名

(iv)修改控制文件中新的数据文件的指针

switch datafile all;

(v)追加归档日志recover数据库

recover database;

脚本大致内容如下：

run {

set until scn 2460383;

set newname for datafile ‘+DATA/prod4/datafile/system.286.905335925‘ to ‘/u01/app/oracle/oradata/CPROD4/datafile/system.dbf‘;

restore database;

switch datafile all;

recover database;

}

具体脚本参考：CPROD4_setNewName_recover.txt

注：脚本执行过程中要tail -f recover_log.log日志文件，跟踪恢复过程

【漫兮网（http://www.manxinet.com）】

6、重建controlfile文件修改redo的恢复路径

recover完成后不能resetlogs方式打开数据库，因为还没有redo文件，没有redo 的情况下，任何到数据库的访问会话都会被oracle kill掉。

该步执行resetlogs方式打开数据库的报错截图如下：

reason：

源端137的redo存放路径在+ FLASHBACK磁盘组

SQL> select member from v$logfile;

MEMBER

---------------------

+FLASHBACK/prod4/onlinelog/group_4.366.905339795

+FLASHBACK/prod4/onlinelog/group_1.368.905339781

+FLASHBACK/prod4/onlinelog/group_2.374.905339785

+FLASHBACK/prod4/onlinelog/group_3.369.905339787

目标端138上没有ASM实例更没有+FLASHBACK磁盘组，所以在执行resetlogs方式打开数据库时不能成功创建redo文件。

解决办法：可以建立和源端137上相同路径的redo存放目录，或者重建控制文件重新指定redo的存放路径

注：默认用resetlogs方式打开数据库时只能创建三个日志组，并且每组只能有一个成员。

solution：

重建controlfile：

执行如下操作：

@mount状态备份控制文件到trace

alter database backup controlfile to trace as

‘/u01/app/oracle/oradata/CPROD4/controlfile/recreateCtl.ctl‘;

@gedit编辑控制文件

gedit /u01/app/oracle/oradata/CPROD4/controlfile/recreateCtl.ctl

重新指定redo的存放路径并以resetlogs方式重建controlfile。

修改后的内容参考脚本：recreateCtl.txt

@执行脚本

SQL > @/u01/app/oracle/oradata/CPROD4/controlfile/recreateCtl.ctl

@一致性关闭数据库

shutdown immediate

@重新加载控制文件

startup mount

7、打开数据库到open状态

alter database open resetlogs;

五、修改日志组，按照业务需求添加日志组及成员

a.添加日志组

alter database add logfile group 4

‘/u01/app/oracle/oradata/CPROD4/onlinelog/redo04a.log‘ size 50m;

b.日志组添加成员

alter database add logfile member

‘/u01/app/oracle/oradata/CPROD4/onlinelog/redo04b.log‘ to group 4;

最终日志组及成员设置情况如下：

注：添加完日志组后要切换下日志组，把unused状态切换到正常状态。

alter system switch logfile;

同时再次确认日志组成员member的status是正常状态。

六、添加临时表空间、临时数据文件

a.查询系统默认临时表空间

select * from database_properties where property_name=‘DEFAULT_TEMP_TABLESPACE‘;

b.查询临时数据文件

select name,status from v$tempfile;

c.对系统默认临时表空间添加临时数据文件

alter tablespace temp add tempfile

‘/u01/app/oracle/oradata/CPROD4/tempfile/temp01.dbf‘ size 300m;

d.根据业务需求添加临时数据文件，最终设置如下：

【漫兮网（http://www.manxinet.com）】

七、校验是否成功恢复到指定SCN

查询v$datafile_header视图确认数据文件头的真实SCN

select name, CHECKPOINT_CHANGE# from v$datafile_header;

确认数据文件头的SCN成功恢复到指定SCN : 2460383

八、完成全库恢复（或测试环境搭建）的整个过程

本文由漫兮首发于【漫兮网（http://www.manxinet.com）】--转载请注明【漫兮网】

以上是关于rman全库恢复到不同主机，不同实例名，不同目录下的主要内容，如果未能解决你的问题，请参考以下文章

使用rman的level0的备份文件迁移oracle数据库-不完全恢复

ORACLERMAN各种情况下的备份恢复

Rman将数据文件恢复到不同的路径

Oracle 11G RMAN 单实例异机恢复

12C CDB模式下RMAN备份与恢复

RAC 之 RMAN 恢复