记录一次Oracle 11.2.0.4 RAC异地恢复到单实例
--原文：http://blog.itpub.net/30484956/viewspace-2688280/
此次记录一下Oracle RAC集群备份异地单实例恢复操作。主要记录关键操作，由于保密原因不粘贴详细操作流程。
一、环境：
原库：
操作系统：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 ch1 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 ch1 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.
至此恢复完成。生产环境在恢复成功后一定要重新进行备份。
