Re: RMAN incarnations and duplicate for standby

Thanks for your reply.

But I am not sure how it would help get past the database incarnation problem. RMAN needs to at least think the current database incarnation is the same one you are recovering to, whether or not you are recovering to a standby or the primary database. Otherwise, it complains about the SET UNTIL time being before the last RESETLOGS.

Anyway, I found a different way around this. Instead of recovering to a standby, I use the standby PFILE as the TARGET instance, since it has the same DB_NAME parameter with different file paths. This allows RMAN to think it is the primary.
( Recovering to a standby was not desired, but seemed like the only way to recover to a separate database. )

Now I can set the incarnation without worrying about messing up the primary database. But I have to manually rename all the datafiles and redo logs, or else it WILL mess up the primary database. Before, when I just issued the DUPLICATE FOR STANDBY command, RMAN did all the renaming automatically. So I basically just adapted the script it generated from the DUPLICATE command.

When it's finished, I just need to make sure that I don't open the new database from within RMAN since it will RESETLOGS and add a new incarnation to the recovery catalog, since RMAN still thinks it is the primary database. But rather, I should reset the incarnation back to what it was before, so I can still recover to the actual primary database.

Here is the RMAN script: (names changed to protect the innocent)

reset database to incarnation 7547;

run
{
set until time "TO_DATE('11/06/2003 00:00:00','MM/DD/YYYY HH24:MI:SS')";

set newname for datafile 1 to "D:\ORACLE\ORADATA\AUXDB\SYSTEM.DBF"; set newname for datafile 2 to "D:\ORACLE\ORADATA\AUXDB\UNDO.DBF"; set newname for datafile 3 to
"D:\ORACLE\ORADATA\AUXDB\USER_DATA.DBF"; set newname for datafile 4 to
"D:\ORACLE\ORADATA\AUXDB\TEMPORARY_DATA.DBF"; set newname for datafile 5 to "D:\AUXDB\XYZ_ARCHIVAL.DBF"; set newname for datafile 6 to "D:\AUXDB\XYZ_IDX_LIVE.DBF"; ...<trimmed for length>...
set newname for datafile 27 to "D:\AUXDB\FOOBAR_DYN_TAB.DBF"; set newname for datafile 28 to "D:\AUXDB\FOOBAR_DYN_IDX.DBF";

restore controlfile to 'E:\TEMP\tmp_cfile.tmp'; restore controlfile from 'E:\TEMP\tmp_cfile.tmp'; alter database mount;

sql "alter database rename file ''D:\ORACLE\ORADATA\MAIN\LOG_1A.LOG'' to ''D:\ORACLE\ORADATA\AUXDB\LOG_1A.LOG''"; sql "alter database rename file ''E:\ORACLE\ORADATA\MAIN\LOG_1B.LOG'' to ''E:\ORACLE\ORADATA\AUXDB\LOG_1B.LOG''"; ...<trimmed for length>...
sql "alter database rename file ''E:\ORACLE\ORADATA\MAIN\LOG_3B.LOG'' to ''E:\ORACLE\ORADATA\AUXDB\LOG_3B.LOG''";

restore database check readonly;
switch datafile all;
recover database check readonly, delete archivelog; }

then, in SQLPLUS:
ALTER DATABASE OPEN RESETLOGS; then, in RMAN, connected to the PRIMARY DATABASE: reset database to incarnation 7935;

The incarnation number is determined using the "LIST INCARNATION" command. The target datbase had to be dismounted before running this script. The PFILE being used had the same DB_NAME as the primary, but a different INSTANCE_NAME. If done correctly, the primary database should not be affected at all.

I hope this info helps anyone else who is simply trying to restore from RMAN to a separate database instance.

Thanks,
Kaptain524

martins_at_imagenet.co.uk wrote in message news:<db24bcb4.0311200835.59ed3216_at_posting.google.com>...
> Kaptain(!?) i recently had to go through all of this, rather than
> answer it point by point, heres how i resolved all of it.
>
> 1. Create standby controlfile in each back.
> In my RMAN script i added "include current controlfile for standby;".
> This made the full backup script:
>
> run {
> # Hot database level 0 whole backup
> configure controlfile autobackup on;
> allocate channel t1 type 'SBT_TAPE';
> allocate channel t2 type 'SBT_TAPE';
> backup
> incremental level 0
> skip inaccessible
> tag hot_bk_week_level0
> filesperset 5
> # recommended format
> format 'imgoradb_bk_%s_%p_%T'
> database
> include current controlfile for standby;
> sql 'alter system archive log current';
> # backup all archive logs
> backup
> filesperset 20
> format 'imgoradb_al_%s_%p_%T'
> (archivelog all
> delete input
> );
> }
>
> It's an overhead, but for a 750Gb database, not a big one.
>
> 2. Use backup to build standby.
> Once i wanted to build the standby, using the latest full backup
> generated above, you do two things.
> a) Find the correct SCN - find the archive logs in the backup (from
> the RMAN logfile) and find the highest 'NEXT_SCN' acroos them all.
> Then 'plug' that in to the 'SET UNTIL SCN' line in the script below
> (we had different file structures):
>
> run
> {
> SET UNTIL SCN 799158965 ;
> # allocate channel t1 type 'SBT_TAPE';
> ALLOCATE AUXILIARY CHANNEL dup1 DEVICE TYPE 'SBT_TAPE'
> parms="ENV=(NB_ORA_CLASS=imgoradb_ora_hot_weekly_new,
> NB_ORA_SERV=imgsrv01, NB_ORA_CLIENT=imgsrv01)";
> ALLOCATE AUXILIARY CHANNEL dup2 DEVICE TYPE 'SBT_TAPE'
> parms="ENV=(NB_ORA_CLASS=imgoradb_ora_hot_weekly_new,
> NB_ORA_SERV=imgsrv01, NB_ORA_CLIENT=imgsrv01)";
> SET NEWNAME FOR DATAFILE 3 TO '/oracle/oradev01/stby/cwmlite01.dbf'
> ;
> SET NEWNAME FOR DATAFILE 4 TO '/oracle/oradata01/stby/drsys01.dbf' ;
> ...
> SET NEWNAME FOR DATAFILE 48 TO '/oracle/oradata01/stby/users07.dbf'
> ;
> DUPLICATE TARGET DATABASE FOR STANDBY
> DORECOVER;
> }
>
> This then uses the correct SCN, which when you connect to the target
> (primary) database means it 'knows' that you have a standby control
> file on tape frm your last backup
Received on Tue Dec 09 2003 - 12:01:10 CST