RAC数据库建立STANDBY（六）

最新推荐文章于 2021-04-07 05:29:36 发布

ckawt40802

最新推荐文章于 2021-04-07 05:29:36 发布

阅读量128

点赞数

文章标签：数据库

这篇文章描述为RAC环境创建STANDBY数据库。

由于篇幅限制，加上碰到了很多的bug，只能将文章拆分成多篇。

由于错误太多，导致一篇文章无法完全记录下来，创建STANDBY数据库问题汇总的第四部分。

RAC数据库建立STANDBY（一）：http://yangtingkun.itpub.net/post/468/484988

RAC数据库建立STANDBY（二）：http://yangtingkun.itpub.net/post/468/485013

RAC数据库建立STANDBY（三）：http://yangtingkun.itpub.net/post/468/485054

RAC数据库建立STANDBY（四）：http://yangtingkun.itpub.net/post/468/485090

RAC数据库建立STANDBY（五）：http://yangtingkun.itpub.net/post/468/485121

刚刚在进行RAC环境的DUPLICATE DATABASE的时候，就碰到了很多问题，由于二者命令比较相似，本来认为这次不会碰到太多的问题，没有想到的是，这次碰到的问题居然比DUPLICATE碰到的问题多出一倍。而且基本上所有碰到的问题都是DUPLICATE操作时不曾遇到的。

bash-3.00$ rman target sys/test@rac11g1 auxiliary sys/test@rac11g1_s

Recovery Manager: Release 11.1.0.6.0 - Production on Tue Sep 9 18:54:07 2008

connected to target database: RAC11G (DBID=1712482917)
connected to auxiliary database: RAC11G (not mounted)

RMAN> run
2> {
3> allocate channel c1 device type disk connect sys/test@rac11g1;
4> allocate channel c2 device type disk connect sys/test@rac11g2;
5> allocate auxiliary channel ac1 device type disk connect sys/test@rac11g1_s;
6> allocate auxiliary channel ac2 device type disk connect sys/test@rac11g1_s;
7> duplicate target database for standby
8> dorecover
9> from active database;
10> }

using target database control file instead of recovery catalog
allocated channel: c1
channel c1: SID=621 instance=rac11g1 device type=DISK

allocated channel: c2
channel c2: SID=254 instance=rac11g2 device type=DISK

allocated channel: ac1
channel ac1: SID=325 instance=rac11g1 device type=DISK

allocated channel: ac2
channel ac2: SID=324 instance=rac11g1 device type=DISK

Starting Duplicate Db at 09-SEP-08

contents of Memory Script.:
{
   backup as copy reuse
   file '/data/oracle/product/11.1/database/dbs/orapwrac11g1' auxiliary format
'/data/oracle/product/11.1/database/dbs/orapwrac11g1'   ;
}
executing Memory Script

Starting backup at 09-SEP-08
Finished backup at 09-SEP-08

contents of Memory Script.:
{
   backup as copy current controlfile for standby auxiliary format '+DATA/rac11g/rac11g_control_1';
   restore clone controlfile to '+DATA/rac11g/rac11g_control_2' from
'+DATA/rac11g/rac11g_control_1';
   restore clone controlfile to '+DATA/rac11g/rac11g_control_3' from
'+DATA/rac11g/rac11g_control_1';
   sql clone 'alter database mount standby database';
}
executing Memory Script

Starting backup at 09-SEP-08
channel c1: starting datafile copy
copying standby control file
output file name=/data/oracle/product/11.1/database/dbs/snapcf_rac11g1.f tag=TAG20080909T184849 RECID=5 STAMP=665002130
channel c1: datafile copy complete, elapsed time: 00:00:03
Finished backup at 09-SEP-08

Starting restore at 09-SEP-08

channel c1: no AUTOBACKUP in 7 days found
channel c2: no AUTOBACKUP in 7 days found
channel ac1: skipped, AUTOBACKUP already found
channel ac2: skipped, AUTOBACKUP already found
channel clone_default: copied control file copy
Finished restore at 09-SEP-08

Starting restore at 09-SEP-08

sql statement: alter database mount standby database

contents of Memory Script.:
{
   set newname for tempfile 1 to
"+DATA/rac11g/rac11g_temp_1_4g";
   set newname for tempfile 2 to
"+DATA/rac11g/rac11g_temp_2_16g";
   switch clone tempfile all;
   set newname for datafile 1 to
"+DATA/rac11g/rac11g_system_1_1g";
   set newname for datafile 2 to
"+DATA/rac11g/rac11g_sysaux_1_1g";
   set newname for datafile 3 to
"+DATA/rac11g/rac11g_undotbs1_1_4g";
   set newname for datafile 4 to
"+DATA/rac11g/rac11g_undotbs2_1_4g";
   set newname for datafile 5 to
"+DATA/rac11g/rac11g_users_1_4g";
   set newname for datafile 6 to
"+DATA/rac11g/rac11g_ndmain_1_32g";
   set newname for datafile 7 to
"+DATA/rac11g/rac11g_ndmain_2_32g";
   set newname for datafile 8 to
"+DATA/rac11g/rac11g_ndmain_3_32g";
   set newname for datafile 9 to
"+DATA/rac11g/rac11g_ndmain_4_32g";
   set newname for datafile 10 to
"+DATA/rac11g/rac11g_ndmain_5_32g";
   set newname for datafile 11 to
"+DATA/rac11g/rac11g_ndmain_6_32g";
   set newname for datafile 12 to
"+DATA/rac11g/rac11g_undotbs1_2_32g";
   set newname for datafile 13 to
"+DATA/rac11g/rac11g_undotbs2_2_32g";
   set newname for datafile 14 to
"+DATA/rac11g/rac11g_perfstat_1_8g";
   backup as copy reuse
   datafile 1 auxiliary format
"+DATA/rac11g/rac11g_system_1_1g"   datafile
2 auxiliary format
"+DATA/rac11g/rac11g_sysaux_1_1g"   datafile
3 auxiliary format
"+DATA/rac11g/rac11g_undotbs1_1_4g"   datafile
4 auxiliary format
"+DATA/rac11g/rac11g_undotbs2_1_4g"   datafile
5 auxiliary format
"+DATA/rac11g/rac11g_users_1_4g"   datafile
6 auxiliary format
"+DATA/rac11g/rac11g_ndmain_1_32g"   datafile
7 auxiliary format
"+DATA/rac11g/rac11g_ndmain_2_32g"   datafile
8 auxiliary format
"+DATA/rac11g/rac11g_ndmain_3_32g"   datafile
9 auxiliary format
"+DATA/rac11g/rac11g_ndmain_4_32g"   datafile
10 auxiliary format
"+DATA/rac11g/rac11g_ndmain_5_32g"   datafile
11 auxiliary format
"+DATA/rac11g/rac11g_ndmain_6_32g"   datafile
12 auxiliary format
"+DATA/rac11g/rac11g_undotbs1_2_32g"   datafile
13 auxiliary format
"+DATA/rac11g/rac11g_undotbs2_2_32g"   datafile
14 auxiliary format
"+DATA/rac11g/rac11g_perfstat_1_8g"   ;
   sql 'alter system archive log current';
}
executing Memory Script

executing command: SET NEWNAME

renamed tempfile 1 to +DATA/rac11g/rac11g_temp_1_4g in control file
renamed tempfile 2 to +DATA/rac11g/rac11g_temp_2_16g in control file

executing command: SET NEWNAME

Starting backup at 09-SEP-08
channel c1: starting datafile copy
input datafile file number=00009 name=/dev/vx/rdsk/datavg/rac11g_ndmain_4_32g
channel c2: starting datafile copy
input datafile file number=00010 name=/dev/vx/rdsk/datavg/rac11g_ndmain_5_32g
RMAN-03009: failure of backup command on c1 channel at 09/09/2008 18:55:34
ORA-19504: failed to create file "+DATA/rac11g/rac11g_ndmain_4_32g"
channel c1 disabled, job failed on it will be run on another channel
RMAN-03009: failure of backup command on c2 channel at 09/09/2008 18:55:34
ORA-19504: failed to create file "+DATA/rac11g/rac11g_ndmain_5_32g"
channel c2 disabled, job failed on it will be run on another channel
released channel: c1
released channel: c2
released channel: ac1
released channel: ac2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/09/2008 18:55:34
RMAN-03015: error occurred in stored script. Memory Script

这个错误是所有错误之中最另人郁闷的，马上就要成功了，没想到碰到了这个错误。查询了metalink，发现有不少ORA-19504错误，但是都和当前问题不完全一致。不过可以肯定一点，问题肯定和ASM有关。

经过再三的测试，发现似乎是由于源数据库发出的连接无法在ASM上恢复数据文件造成的。回想前面碰到的SPFILE的问题，感觉这种FROM ACTIVE DATABASE方式的STANDBY建立方法，如果STANDBY数据库选择了ASM方式存储，那么会导致源数据库的连接无法在ASM上面恢复数据库。

由于metalink上没有详细的描述，而且Oracle的错误提示信息也十分有限，所以到这一步暂时没有办法继续恢复了。而唯一的方法就是绕过这个问题，于是后面的测试又回到了使用备份文件进行STANDBY创建的过程。

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

Recovery Manager: Release 11.1.0.6.0 - Production on Wed Sep 10 09:53:12 2008

connected to target database: RAC11G (DBID=1712482917)
connected to recovery catalog database
connected to auxiliary database: RAC11G (not mounted)

allocated channel: c1
channel c1: SID=285 instance=rac11g1 device type=DISK

allocated channel: c2
channel c2: SID=104 instance=rac11g2 device type=DISK

allocated channel: ac1
channel ac1: SID=307 instance=rac11g1 device type=DISK

allocated channel: ac2
channel ac2: SID=306 instance=rac11g1 device type=DISK

Starting Duplicate Db at 10-SEP-08

contents of Memory Script.:
{
   set until scn 29148537;
   restore clone standby controlfile;
   sql clone 'alter database mount standby database';
}
executing Memory Script

executing command: SET until clause

Starting restore at 10-SEP-08

channel ac1: restoring control file
ORA-19625: error identifying file /data/oracle/product/11.1/database/dbs/snapcf_rac11g1.f
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-19600: input file is control file (/data/oracle/product/11.1/database/dbs/snapcf_rac11g1.f)
ORA-19601: output file is control file (+DATA/rac11g/rac11g_control_1)

failover to previous backup

channel ac1: starting datafile backup set restore
channel ac1: restoring control file
channel ac1: reading from backup piece /data/oracle/product/11.1/database/dbs/09jq63m1_1_1
channel ac1: ORA-19870: error while restoring backup piece /data/oracle/product/11.1/database/dbs/09jq63m1_1_1
ORA-19505: failed to identify file "/data/oracle/product/11.1/database/dbs/09jq63m1_1_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

failover to previous backup

channel ac1: starting datafile backup set restore
channel ac1: restoring control file
channel ac1: reading from backup piece /data/01jpk0bj_1_1
channel ac1: 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

released channel: c1
released channel: c2
released channel: ac1
released channel: ac2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/10/2008 09:53:45
RMAN-03015: error occurred in stored script. Memory Script
RMAN-06026: some targets not found - aborting restore
RMAN-06024: no backup or copy of the control file found to restore

终于是最后一个问题了，这个问题其实是在测试DUPLICATE时碰到了，由于Oracle要根据源数据库备份集的路径，在STANDBY数据库的相同位置寻找备份集，所以报错找不到指定的备份集。

只需要根据前面介绍的方法，通过CATALOG方式，编辑CATALOG数据库中BACKUP_PIECE的位置，来骗过Oracle。

具体的方法这里就不重复了，可以参考下面的文章：http://yangtingkun.itpub.net/post/468/471421

没有想到，创建STANDBY过程，准备加上创建脚本写了一篇文章，后期的检查和整理写了一篇文章，而碰到的问题却足足写了四篇。

当然原因是多方面的，RAC环境部署STANDBY相对比较复杂，而且利用DUPLICATE进行STANDBY的创建以前做的也不多。加上FROM ACTIVE DATABASE是11g的新特性，一些bug在所难免，在加上ASM的众多bug，想不碰到问题都比较困难。不过其中一个很重要的原因在于，STANDBY和PRIMARY数据库的物理存储方式不等同，如果采用相同的配置，可能问题会相对少一些。