Re: Resuming an aborted RMAN database duplication

OK now that I've RTFM'ed Robert's 10g RMAN Backup & Recovery book
(which I've had on my shelf for almost a month), I see this:

"With RESTORE OPTIMIZATION turned ON, RMAN will not restore files
again that already exist in the restore location with the same
datafile header SCN information.  This applies to duplication as well:
if duplication restores a file, and then duplication restarts, RMAN
will not restore the file again.  However, if you have applied even
one archive log to the file, it will be restored again."

Other reference material (Backup and Recovery Advanced User's Guide)
indicate that RMAN will ALWAYS behave that way, and don't mention a
changeable parameter regarding "restore optimization".  My target
instance does have "BACKUP OPTIMIZATION" on.  However I'm running the
duplication from the host of the auxiliary instance, which has no
prior RMAN configurations.

The log indicates to me that it was still applying incremental
backups, not yet doing archivelog recovery.  Here's it the log snippet
before failure:

channel aux8: starting incremental datafile backupset restore
channel aux8: specifying datafile(s) to restore from backup set
... list of datafiles ...
channel aux8: reading from backup piece /rman/bvig5trp_1_1
... messages showing channels being released ...
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 04/27/2007 13:31:10
RMAN-03015: error occurred in stored script Memory Script
ORA-19870: error reading backup piece /rman/bvig5trp_1_1
ORA-19505: failed to identify file "/rman/bvig5trp_1_1"
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Any thoughts?

Also on page 485 of the Freeman/Hart 10g book, there is a typo
resulting in "ORALCE_HOME".  ;)

On 4/27/07, Don Seiler <don@xxxxxxxxx> wrote:
Robert,

This time I had RMAN abort due to a backup piece missing (rsync was
started too early).  We are doing a DUPLICATE DATABASE and renaming
data/log files in the process to directories based on a new SID.

How does one pick up from here, once I get all the backup pieces in
place?  I've tried re-running the duplicate command, hoping against
hope that it will be smart enough to just pick up on its own, but it
doesn't look that way.

Don.

On 4/19/07, Robert Freeman <robertgfreeman@xxxxxxxxx> wrote:
>
>
> Extract them (restore archive log) and then apply manually.
>
> RF
>
>
>
> Robert G. Freeman
> Oracle Press Author
> Principle Engineer/Team Manager
> The Church of Jesus Christ of Latter-Day Saints
> Collaborate '07
> Come join my APEX University Session
> and Join me to talk about Evolutionary Database Development!!
> The LDS Church is Hiring DBAs! Contact me if you are interested!
>
>
> -----Original Message-----
> From: jayaraj rengarajan [mailto:jayaraj.rengarajan@xxxxxxxxx]
> Sent: Thursday, April 19, 2007 6:34 PM
> To: robertgfreeman@xxxxxxxxx
> Cc: don@xxxxxxxxx; oracle_l
> Subject: Re: Resuming an aborted RMAN database duplication
>
>
> Bob-
>
> If archived logs backup are thr' RMAN, How would you apply these archived
> log backup pieces manually for PTR ?
>
> Thanks
> Jay
>
>
> On 4/16/07, Robert Freeman <robertgfreeman@xxxxxxxxx> wrote:
> > If the datafiles were restored successfully, then it's
> > just a matter of manually restoring any needed
> > archived redo logs to the new database and applying
> > them manually. Then open the database. You will have
> > to do this as a point in time recovery, and just
> > recover to the last archived redo log sequence that
> > you restored.
> >
> > You may also want to reset the DBID if RMAN has not
> > done so already.
> >
> > Robert
> >
> > --- Don Seiler <don@xxxxxxxxx> wrote:
> >
> > > This weekend I was running an RMAN database
> > > duplication to migrate our
> > > development instances from 32-bit server with
> > > file-based storage to
> > > 64-bit server using ASM.  I've done this once
> > > already and it went
> > > virtually fine.
> > >
> > > However this time we got errors while RMAN was
> > > restoring the archived
> > > logs.  I presume that archived logs would be towards
> > > the end of the
> > > process, and this was already after 6+ hours.  We
> > > believe the error to
> > > be due to a bug in the failover logic in the qlogic
> > > drivers, and have
> > > disabled it for now.  Reissuing my command basically
> > > started the
> > > process over from scratch.
> > >
> > > I'm wondering if there is a method available to have
> > > the DUPLICATE
> > > DATABASE or maybe just manually, restore the
> > > remaining archived logs
> > > and then move on to recovery and database opening.
> > > It seems silly to
> > > have to do another 6 hour datafile restore.
> > >
> > > I could swear that RMAN did know when files didn't
> > > need to be restored
> > > and would skip over them.  Perhaps that was for a
> > > "restore database"
> > > command.
> >
> > Robert G. Freeman
> > Author:
> > Portable DBA: Oracle  (Oracle Press)
> > Oracle Database 10g New Features (Oracle Press)
> > Oracle9i RMAN Backup and Recovery (Oracle Press)
> > Oracle9i New Features (Oracle Press)
> > Oracle Replication (Rampant Tech Press)
> > Mastering Oracle8i (Sybex)
> > Oracle8 to 8i Upgrade Exam Cram (Coriolis <RIP>)
> > Oracle 7.3 to 8 Upgrade Exam Cram (Coriolis <RIP>)
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> >
>
>


--
Don Seiler
oracle blog: http://ora.seiler.us
ultimate: http://www.mufc.us
--
http://www.freelists.org/webpage/oracle-l


Other related posts: