strange controlfile problem with RMAN

From: Kaptain524 <Kaptain524_at_zxmail.com>
Date: 20 Oct 2003 15:13:32 -0700
Message-ID: <3f6a20bd.0310201413.41e8ce90@posting.google.com>

Hello,

For some reason, when I create a standby database with RMAN (on same box but different directories), the original controlfile sometimes gets replaced with the standby controlfile. This causes very strange problems. Mainly, it prevents RMAN from logging in. And if I shutdown the production instance, it won't start up again, or only starts as a standby. Mounting the controlfile causes the sys password to change to the one for the standby instance. Currently, when this happens, I use RMAN to restore the production controlfile and it fixes it, unless some transactions took place since the control was backed up. Then I have to do a full recovery on the production instance.

Can anyone figure out how I can prevent RMAN from changing the original controlfile when I duplicate the database for standby with recovery? Or is there any way I can safely restore the control file should this happen? I don't want to have to dismount the production instance, but I may have no choice...

The PFILE for the standby instance differs from the original as follows:

1. all "_dest" params have different paths (except log_archive_dest).
2. the control file paths are different.
3. added LOCK_NAME_SPACE param with value other than production sid
4. added DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT params to

change paths to datafiles and logfiles.

Here is the rman code that I am using:

rman> connect target sys/prodsys_at_prod;
rman> connect catalog rman/rcatusr_at_rcat;
rman> backup database include current controlfile for standby;
rman> sql 'alter system archive log current';

rman> connect target sys/prodsys_at_prod;
rman> connect catalog rman/rcatusr_at_rcat;
rman> connect auxiliary sys/auxsys_at_auxdb;

rman> run {
rman> set until time "TO_DATE('10/1/2003 12:00:00','MM/DD/YYYY HH24:MI:SS')";
rman> duplicate target database for standby dorecover; rman> }

The output from this process shows no indication that the original controlfile would be changed at all. I think there may be a bug somewhere, but I am not sure if it RMAN's fault or my own.

Any suggestions?

Thanks,
Kaptain524 Received on Mon Oct 20 2003 - 17:13:32 CDT