Re: Interesting RMAN duplicate problem.

From: Robert Freeman <>
Date: Wed, 27 Jan 2010 08:26:22 -0800 (PST)
Message-ID: <>

Once in a while (especially in 9i) I would get weird problems with RMAN duplicate. My solution often was to do the following:
  1. Do the duplicate. It would fail as you describe.
  2. Start a manual recovery using the SQL*Plus recover database until cancel command. You can use until time, etc.
  3. Manually extract archived redo logs from the source system as required for the recovery on the duplicate.
  4. Once I'm at the point I want to open the database, I would open the database using resetlogs.

The problem often involved a case where the recovery point-in-time was contained in an online redo log that was not archived yet (the current online redo log). You can, of course, use the V$ views (ie: V$RECOVER_FILE, V$DATAFILE, etc...) to determine the state of the data files, and their consistency.



 Robert G. Freeman
Oracle ACE
Ask me about on-site Oracle Training! RMAN, DBA, Tuning, you name it! Author:
Oracle Database 11g RMAN Backup and Recovery (Oracle Press) - ON ITS WAY SOON! OCP: Oracle Database 11g Administrator Certified Professional Study Guide (Sybex) Oracle Database 11g New Features (Oracle Press) Oracle Database 10g New Features (Oracle Press) Other various titles
Blog: Check out my new blog series on installing Oracle Database 11gR2 on Windows using VMWare!

From: Marcin Przepiorowski <> To: Cc:; oracle-l <> Sent: Wed, January 27, 2010 8:30:15 AM
Subject: Re: Interesting RMAN duplicate problem.

On Wed, Jan 27, 2010 at 2:12 PM, Dunbar, Norman <> wrote:
> Hi Pete,
>>> If you try the "recover database until cancel" command in
>>> sql*plus, what does it ask for?
> A missing log file that I do not have - sequence 675041. This is higher
> than the range of sequences in the archivelog backup - 674565 - 674627.


Did you apply all these archive log between 674565 - 674627 ? Check alert log if all of those had been applied without errors.

If restore process is asking about higher sequence there is a chance that control file is a newer than data files.

Did you try with recreation of control file ?

  1. backup current control file to trace
  2. shutdown db
  3. copy current control file - just in case
  4. startup nomount
  5. use trace file to recreate control file with resetlog option

Duplication process without until time restriction is trying to restore DB to current production state
and if I remember correctly there was some issues related to that in 9i - but most of them could be solved via control file recreation.


Received on Wed Jan 27 2010 - 10:26:22 CST

Original text of this message