记录一次Oracle11.2.0.4RAC异地恢复到单实例

此次记录一下Oracle RAC集群备份异地单实例恢复操作。主要记录关键操作，由于保密原因不粘贴详细操作流程。

东昌ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18982081108（备注：SSL证书合作）期待与您的合作！

一、环境：

原库：

操作系统：Redhat 6.5
数据库：Oracle 11.2.0.4 RAC （双节点）
工具：rman
IP地址：192.168.10.10（节点1）

异地恢复库：

操作系统：Centos 6.5
数据库：Oracle 11.2.0.4 （单实例）
工具：rman
IP地址：192.168.10.123

二、操作

1.原库两个节点全部停止应用服务，停掉监听，防止再有连接进来进行操作。然后在一个节点（192.168.10.10）使用 rman工具进行整库备份，在执行备份前手动归档一次，主要备份数据库、归档文件、控制文件。至于spfile参数文件可以不用备份，因为RAC环境的参数文件到单实例上还是需要修改很多地方的，可以在原库使用命令 create pfile=’/home/oracle/orclint.ora’ from spfile 生成pfile文件。

2.将备份后的数据库、归档、控制文件以及生成的pfile文件使用scp远程复制到192.168.10.123（异地库），放在了/data/rmanbackup目录下

3.192.168.10.123（异地库）已经安装了Oracle 11.2.0.4软件，并未建库。设置环境变量，尤其是ORACLE_SID与192.168.10.10（原库）集群环境一致，便于恢复操作。

4.根据传过来的pfile文件里的内容进行修改，我大致列一下修改后的参数文件：

*.audit_file_dest='/u01/app/oracle/admin/hkrt/adump'
*.audit_trail='db'
*.compatible='11.2.0.4.0'
*.control_files='/u01/app/oracle/oradata/hkrt/control01.dbf','/u01/app/oracle/oradata/hkrt/control02.dbf'
*.db_block_size=8192
*.db_domain=''
*.db_name='ORCL'
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=hkrtXDB)'
*.log_archive_dest_1='LOCATION=/u01/arch'
*.log_archive_format='%t_%s_%r.dbf'
*.memory_target=5034213376
*.open_cursors=300
*.processes=400

5.参数文件修改完后剩下的操作基本都在异地库了，sqlplus进入空实例，然后根据修改后的pfile进行启动到nomount状态（注意：参数文件中的内存配置、进程数配置要符合异地库内存，不然内存溢出，启动失败）。

参考命令：
startup nomount from pfile=’/data/rmanbackup/orclinit.ora’;

（由于是测试，所有并没有备份密码文件，可以在数据库恢复后重置用户密码）

6.讲数据库启动到nomount状态，登陆rman （rman target /），就可以看到数据库状态为nomount状态。然后进行控制文件的恢复，参考命令：

restore controlfile from ‘/data/rmanbackup//ctl_ORCL_20150830_6552_1’;

执行完控制文件还原操作后，控制文件会恢复到参数文件中指定的目录下

7.控制文件恢复后就可以启动到mount状态了，

RMAN> alter database mount;

启动到mount状态先别着急恢复数据库，需要先将备份集注册到rman中

RMAN> catalog start with ‘/data/rmanbackup’;

（路径就是你存放所有备份的目录）

注册完成后，先交叉校验备份集：

RMAN> crosscheck backupset;

删除过期的备份，因为你备份是异地备份，所以在RAC中记录的备份全部过期，进行清除

RMAN> delete expired backup;

8.现在开始恢复数据库文件，因为RAC数据库数据文件、日志文件等存储路径时在ASM磁盘中，路径基本是以 ‘+DATA’ 开头，在执行restore database 命令前需要进行文件路径转换。

先在原库上生成关于数据文件路径转换的脚本，便于恢复操作，脚本如下（在原库查询得出脚本）：

select 'set newname for datafile ' || a.FILE# || ' to "' || a.NAME || '";' from v$datafile a
union all
select 'set newname for tempfile ' || a.FILE# || ' to "' || a.NAME || '";' from v$tempfile a;

得到结果为：

SETNEWNAMEFORDATAFILE'||A.FILE#||'TO"'||A.NAME||'";'--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------set newname for datafile 1 to "+DATA/jmrac/datafile/system.268.877470209";set newname for datafile 2 to "+DATA/jmrac/datafile/sysaux.269.877470211";set newname for datafile 3 to "+DATA/jmrac/datafile/undotbs1.270.877470213";set newname for datafile 4 to "+DATA/jmrac/datafile/users.271.877470213";set newname for datafile 5 to "+DATA/jmrac/datafile/example.279.877470401";set newname for datafile 6 to "+DATA/jmrac/datafile/undotbs2.280.877470779";set newname for tempfile 1 to "+DATA/jmrac/tempfile/temp.278.877470381";。。。。。。。。

会将所有涉及到的数据文件全部显示，我这里就简单写个大概，得到以上脚本后进行简单的编辑：

run{allocate channel ch2 device type disk;set newname for datafile 1 to "+DATA/jmrac/datafile/system.268.877470209";set newname for datafile 2 to "+DATA/jmrac/datafile/sysaux.269.877470211";set newname for datafile 3 to "+DATA/jmrac/datafile/undotbs1.270.877470213";set newname for datafile 4 to "+DATA/jmrac/datafile/users.271.877470213";set newname for datafile 5 to "+DATA/jmrac/datafile/example.279.877470401";set newname for datafile 6 to "+DATA/jmrac/datafile/undotbs2.280.877470779";set newname for tempfile 1 to "+DATA/jmrac/tempfile/temp.278.877470381";。。。。。。。。
restore database;switch datafile all;switch tempfile all;}

然后就可以在rman中运行以上修改好的 run 块（脚本）进行数据库恢复。此处我并没有生成关于redo日志的转换语句，因为我在讲redo日志转换放到 run脚本块中执行总会提示 +DATA开头的路径不存在，所以就省略了redo，但是我发现数据库恢复并未受影响，而且在恢复后redo日志路径已经转换了。

9.在执行以上 run 脚本命令后，会提示报错：

RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of restore command at 03/25/2015 09:56:55RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore

其实所有的备份都在，就是报这个错，然后查看资料，需要进行一下操作：

RMAN> list incarnation;

List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

1 1 JBDB 1285701182 PARENT 1 15-AUG-09
2 2 JBDB 1285701182 PARENT 945184 12-JUL-13

然后又在原库上做同样的查询：

RMAN> list incarnation;

List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

1 1 JBDB 1285701182 PARENT 1 15-AUG-09
2 2 JBDB 1285701182 PARENT 945184 12-JUL-13

然后在异地库重置 incarnation 为2：

RMAN> reset database to incarnation 2;

执行后再次执行 run 脚本块：

RMAN> run{
allocate channel ch2 device type disk;
set newname for datafile 1 to "+DATA/jmrac/datafile/system.268.877470209";
set newname for datafile 2 to "+DATA/jmrac/datafile/sysaux.269.877470211";
set newname for datafile 3 to "+DATA/jmrac/datafile/undotbs1.270.877470213";
set newname for datafile 4 to "+DATA/jmrac/datafile/users.271.877470213";
set newname for datafile 5 to "+DATA/jmrac/datafile/example.279.877470401";
set newname for datafile 6 to "+DATA/jmrac/datafile/undotbs2.280.877470779";
set newname for tempfile 1 to "+DATA/jmrac/tempfile/temp.278.877470381";
。。。。。。。。
restore database;switch datafile all;switch tempfile all;}

执行正常进行，恢复没有出现问题。

10.数据库文件恢复后，执行recover database会报错，提示缺少归档文件：

RMAN> recover database; Starting recover at 
using channel ORA_DISK_1
starting media recovery
RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of recover command at 
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 71125 and starting SCN of 16888076231found to restore

两种方式：
一是在原库找到归档文件然后传到异地库服务器，注册归档信息，然后再次recover恢复数据库，前提是归档文件能找到。

注册归档信息(归档文件为 arch_71125_xxxx)：

RMAN> catalog archivelog ‘/data/rmanbackup/arch_71125_xxxx’;

RMAN> recover database;

(恢复时提示找不到一个unknow的归档，不影响恢复)

二是按照提示的scn进行不完全恢复：
RAMN> run{
set until scn 16888076231;
recover database;
}

因为我归档文件并未找到，所以是第二种方式。

11.恢复完成后登陆数据库然后打开数据库（resetlogs方式）：

SQL> alter database open resetlogs;

Database altered.

至此恢复完成。生产环境在恢复成功后一定要重新进行备份。

以上是大概的操作过程，仅供参考，在生产环境执行时一定要慎之又慎，做好数据备份，如果有不同情况，也欢迎评论交流，共同学习。