RMAN 8i - Recovery vs duplicate - using different checkpoints???

From: BD <bobby_dread_at_hotmail.com>
Date: 30 Sep 2005 11:48:02 -0700
Message-ID: <1128106082.789638.208130@f14g2000cwb.googlegroups.com>

Hey, all...

So what's RMAN doing under the hood here?

I have a full backup of a db which I am using as a source for both restores and duplications. I'm testing and getting familiar with RMAN.

I am not using any 'UNTIL' parameters in either the restore or the duplicate strings, and yet the Restore succeeds and the Duplicate fails. - they are trying to restore to different SCNs!! Should they not be doing a 'complete' recovery in each case??

I went through the RMAN troubleshooting guide, and it suggests imposing a SET UNTIL SCN# in cases like this - great - but why does the restore work while the Duplicate fails??

Here is my RESTORE script:

run {allocate channel ch1 type disk; sql "alter session set nls_date_format=''YYYY-MM-DD HH24:MI:SS''"; restore database; switch datafile all; recover database;}

---

Here is the end of my RESTORE RMAN session:

RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-08055: media recovery complete
RMAN-03022: compiling command: recover(4)
RMAN-08031: released channel: ch1

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

Here is the end of my alert log for the restored database:

Fri Sep 30 09:22:07 2005
alter database recover if needed
start
Media Recovery Start
Media Recovery Log
Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0  Mem# 0 errs 0: /fs03/oradata/CTD2/redo_log_1a.dbf  Mem# 1 errs 0: /fs04/oradata/CTD2/redo_log_1b.dbf Media Recovery Complete
Completed: alter database recover if needed start

And now, the failed dupe:

Here is the Duplicate command:

run {

     allocate auxiliary channel dupdb1 type disk;
     allocate auxiliary channel dupdb2 type disk;

    allocate auxiliary channel dupdb3 type disk;     allocate auxiliary channel dupdb4 type disk;     set newname for datafile 1 TO
'/rs01/oradata/CTD2_DUP/system_CTD2_01.dbf';

    .
    .*omitting all the rest of the newname commands
    .

    set newname for datafile 43 TO
'/rs01/oradata/CTD2_DUP/arch_tbl_CTD2_01.dbf';

    duplicate target database to CTD2_DUP logfile

      group 1 ('/rs01/oradata/CTD2_DUP/redo_log_1a.dbf',


               '/rs01/oradata/CTD2_DUP/redo_log_1b.dbf') size 200K

reuse,
      group 2 ('/rs01/oradata/CTD2_DUP/redo_log_2a.dbf',


               '/rs01/oradata/CTD2_DUP/redo_log_2b.dbf') size 200K

reuse,
      group 3 ('/rs01/oradata/CTD2_DUP/redo_log_3a.dbf',


               '/rs01/oradata/CTD2/redo_log_3b.dbf') size 200K reuse

   nofilenamecheck;
  }

---

Here is the end of the RMAN session:

RMAN-03002: failure during compilation of command
RMAN-03013: command type: Duplicate Db
RMAN-03015: error occurred in stored script Memory Script
RMAN-03002: failure during compilation of command
RMAN-03013: command type: recover
RMAN-03002: failure during compilation of command
RMAN-03013: command type: recover(4)
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 1 scn 2203057304832 found to

restore

RMAN> **end-of-file**

---

Here is the end of the duplicate db's alert log:

Media Recovery Start
Media Recovery Log
ORA-279 signalled during: alter database recover if needed start until chan...
Fri Sep 30 10:04:57 2005
alter database recover cancel
Media Recovery Cancelled
Completed: alter database recover cancel

Once again (*sigh*), all responses are appreciated.

BD Received on Fri Sep 30 2005 - 13:48:02 CDT