DUPLICATE到底做了什么？

有一个问题一直想不明白，为什么在做DUPLICATE时要同时连接两个库呢。
在以前的版本中备份文件已经复制到目标机器上了，包括控制文件，
所以一直想不明白。为什么要同时连接两个库呢。
和恢复到底有什么区别。
现在是11G了DUPLICATE的做法和以前有点不同了。但还是要同时连接两个库。为什么呢，为什么呢？
转一个大师 yangtingkun的实验，在这做个说明。希望大师能给出答案。

恢复之RAC数据库DUPLICATE（一）

===========================================================

作者: yangtingkun(http://yangtingkun.itpub.net)
发表于: 2008.09.29 23:07
分类: ORACLE
出处: http://yangtingkun.itpub.net/post/468/471508
---------------------------------------------------------------

利用现有环境创建一个DUPLICATE RAC环境。

由于篇幅限制，这篇描述DUPLICATE命令的准备工作。

原数据库为ORACLE RAC 11.1.0.6加上Volumn Cluster Manager，而用来恢复的目标服务器仍然是Oracle RAC 11.1.0.6，不过使用了ASM作为存储方式。

目标数据库的Oracle rac环境已经建立，ASM也已经启动，而且有一个源数据库的备份，已经放到了ASM磁盘组中，下面开始恢复过程。

由于数据库本身比较大，因此不打算采用网络传输的ACTIVE DATABASE方式，而是将备份集拷贝到本地进行恢复。

首先检查当前环境：

$ env|grep ORA
ORACLE_BASE=/data/oracle
ORACLE_HOME=/data/oracle/product/11.1/database
ORACLE_SID=rac 11g 1

编辑一个最简单的初始化参数，启动AUXILIARY实例：

db_name=rac11gs

下面通过这个初始化参数启动实例：

bash-3.00$ rman target/

Recovery Manager: Release 11.1.0.6.0 - Production on Mon Sep 8 15:16:50 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database (not started)

RMAN> startup nomount pfile=initrac 11g 1.ora

Oracle instance started

Total System Global Area 217219072 bytes

Fixed Size 2093360 bytes
Variable Size 160362192 bytes
Database Buffers 50331648 bytes
Redo Buffers 4431872 bytes

下面退出rman，然后分别连接两个实例：

RMAN> exit

Recovery Manager complete.
bash-3.00$ rman target sys/test@172.0.2.54/rac 11g .us.oracle.com auxiliary /

Recovery Manager: Release 11.1.0.6.0 - Production on Mon Sep 8 15:33:10 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: RAC 11G (DBID=1712482917)
connected to auxiliary database: RAC11GS (not mounted)

RMAN>

由于当前节点的备份集和源节点备份集路径不一样，源节点采用本地磁盘的方式存储备份集，而目标节点采用ASM的方式存放备份集，所以常规方法无法解决源节点和目标节点之间备份集不一致的问题。

如果不解决这个问题而直接进行DUPLICATE，则报错如下：

bash-3.00$ rman target sys/test@172.0.2.54/rac 11g .us.oracle.com auxiliary /

Recovery Manager: Release 11.1.0.6.0 - Production on Mon Sep 8 17:49:00 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: RAC 11G (DBID=1712482917)
connected to auxiliary database: RAC11GS (not mounted)

RMAN> duplicate target database to rac11gs
2> db_file_name_convert '/dev/vx/rdsk/datavg', '+DATA/RAC 11G '
3> spfile
4> parameter_value_convert '/dev/vx/rdsk/datavg', '+DATA/RAC 11G '
5> set log_file_name_convert '/dev/vx/rdsk/datavg', '+DATA/RAC 11G '
6> set log_archive_dest_1='LOCATION=+DATA/RAC 11G '
7> set local_listener = ''
8> ;

Starting Duplicate Db at 08-SEP-08
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=113 device type=DISK

contents of Memory Script:
{
set until scn 26685490;
restore clone spfile to '/data/oracle/product/11.1/database/dbs/spfilerac 11g 1.ora';
sql clone "alter system set spfile= ''/data/oracle/product/11.1/database/dbs/spfilerac 11g 1.ora''";
}
executing Memory Script

executing command: SET until clause

Starting restore at 08-SEP-08
using channel ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: restoring SPFILE
output file name=/data/oracle/product/11.1/database/dbs/spfilerac 11g 1.ora
channel ORA_AUX_DISK_1: reading from backup piece /data/01jpk0bj_1_1
channel ORA_AUX_DISK_1: ORA-19870: error while restoring backup piece /data/01jpk0bj_1_1
ORA-19505: failed to identify file "/data/01jpk0bj_1_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

failover to previous backup

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/08/2008 17:49:21
RMAN-03015: error occurred in stored script Memory Script
RMAN-06026: some targets not found - aborting restore
RMAN-06729: no backup of the SPFILE found to restore

RMAN> exit

Recovery Manager complete.

根据Oracle的文档，当源节点和目标节点位置不一样的时候，常规的方式是在源节点根据目录节点的位置创建目录，并将备份集拷贝到目录中，通过CATALOG方式添加新的位置，但是由于目标数据库采用ASM方式，所以这种方式也是不可行的，首先源数据库没有采用ASM的方式，其次，源数据库也没有足够的共享空间来创建ASM磁盘组来容纳备份集。

那么只剩下一个办法，就是通过修改CATALOG数据库中记录的方式来骗过RMAN，关于这个方法的具体描述可以参考：

下面找一个同版本的数据库建立CATALOG账号，对于测试数据库而言，也可以直接在源数据库上建立CATALOG：

SQL> conn / as sysdba已连接。
SQL> create user catalog_user identified by catalog_user
2 default tablespace yangtk
3 quota unlimited on yangtk;

用户已创建。

SQL> grant recovery_catalog_owner to catalog_user;

授权成功。

SQL> host;
$ rman catalog catalog_user/catalog_user

恢复管理器: Release 11.1.0.6.0 - Production on 星期一 9月 8 18:28:19 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

连接到恢复目录数据库

RMAN> create catalog;

恢复目录已创建

下面连接target数据库，catalog数据库和auxiliary数据库，注册数据库并同步备份信息：

bash-3.00$ rman target sys/test@172.0.2.54/rac 11g .us.oracle.com catalog catalog_user/catalog_user@172.0.2.61/test 11g .netdb auxiliary /

Recovery Manager: Release 11.1.0.6.0 - Production on Mon Sep 8 18:33:30 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: RAC 11G (DBID=1712482917)
connected to recovery catalog database
connected to auxiliary database: RAC11GS (not mounted)

RMAN> register database;

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

下面就可以修改catalog库中catalog_user用户下对应的记录了：

SQL> conn catalog_user/catalog_user已连接。
SQL> col handle format a60
SQL> select bp_key, handle from rc_backup_piece;

BP_KEY HANDLE
---------- ------------------------------------------------------------
1475 /data/01jpk0bj_1_1

SQL> update rc_backup_piece set handle = '+DATA/backup/01jpk0bj_1_1'
2 where bp_key = 1475;

已更新 1 行。

SQL> commit;

提交完成。

修改完成后，就可以RMAN会话中执行DUPLICATE命令了。最终使用的DUPLICATE命令如下：

duplicate target database to rac11gs
db_file_name_convert '/dev/vx/rdsk/datavg', '+DATA/RAC 11G '
spfile
parameter_value_convert '/dev/vx/rdsk/datavg', '+DATA/RAC 11G '
set log_file_name_convert '/dev/vx/rdsk/datavg', '+DATA/RAC 11G '
set log_archive_dest_1='LOCATION=+DATA/RAC 11G '
set local_listener = ''
set cluster_database = 'false'
;

为了DUPLICATE不需要设置繁琐的初始化参数，可以先去掉参数中的LOCAL_LISTENER的设置，等到启动之后在重新设置。

将参数CLUSTER_DATABASE设置为FALSE，是为了避免在创建控制文件时出现错误，详细描述可以参考文章：

还要注意将归档日志文件拷贝到目标服务器上和源数据库相同的目录下，否则执行会报错RMAN-6025错误，详细描述可以参考：

在最终执行DUPLICATE命令之前，还需要确保将源数据库中tnsnames.ora中的LISTENERS_RAC 11G 的配置添加到本地数据库的tnsnames.ora中，否则启动会报错找不到REMOTE_LISTENER。

而且需要在DUPLICATE的目标节点上建立对应的目录：

$ mkdir -p /data/oracle/admin/rac 11g /adump
$ mkdir /data/oracle/admin/rac 11g /dpdump
$ mkdir /data/oracle/admin/rac 11g /hdump
$ mkdir /data/oracle/admin/rac 11g /pfile
$ mkdir /data/oracle/admin/rac 11g /scripts
$ mkdir -p /data/oracle/diag/rdbms/rac 11g /rac 11g 1/alert

所有这些都准备好了，下面可以执行DUPLICATE命令了。

使用DUPLICATE的原因。

一直想知道ORACLE在DUPLICATE中到度隐藏了什么，既然在做DUPLICATE时ORACLE要将所有备份文件复制到目标机上那又为什么要同时连接两个库：target instance and auxiliary instance.
开始以为是使用了源机器上的控制文件，因为控制文件里面有备件文件的信息，但既然控制文件的备份已经被复制到目标机上，又为什么不能将控制文件恢复然后再做普通的恢复。因为普通的恢复不需要连接源数据库了。
毕竟源数据库是PRODUCTION，连接到源库上后操作总是小心翼翼。
之所以最近总被这个问题困扰，原因就是最近我的DR库在使用DUPLICATE恢复时总是报错。

分析DUPLICATE：
1：在使用恢复目录的情况下，必需使用DUPLICATE。因为DUPLICATE会修改DBID，这样不会在恢复目录中引起数据库注册问题，如果没有使用恢复目录，其实DUPLICATE和普通恢复区别不大。
2：控制文件还是要重新建立的。DUPLICATE之所以要连接到源数据库，是因为在恢复过程中要使用源数据库的控制文件里面的备件信息，先恢复数据文件，然后重新创建控制文件，恢复归档日志，更改DBID，最后建立日志文件，打开数据库。

同理在做表空间的及时恢复时同时连接两个实例也是因为要在恢复过程中要使用源数据库里面的控制文件。
http://blog.csdn.net/henrybai/archive/2008/11/05/3216980.aspx