Re: Duplicate Database with RMAN

On Mar 23, 5:17 pm, "Jeff B" <jbis..._at_yahoo.com> wrote:
> On Mar 16, 11:33 am, "Keith" <kkna..._at_gmail.com> wrote:
>
>
>
> > On Mar 16, 8:33 am, "EdStevens" <quetico_..._at_yahoo.com> wrote:
>
> > > On Mar 15, 6:18 pm, "Jeff B" <jbis..._at_yahoo.com> wrote:
>
> > > > This is probably too much to ask, but what have I got to lose. :) Can
> > > > someone possibly provide an RMAN script/process for duplicating a
> > > > database with RMAN? My source database would need to be a backup of a
> > > > production database one one server, and then I would like to move it
> > > > to a destination instance (testdb) on another server. The databases
> > > > do not have the same name, but they have the same structure.
>
> > > > Thanks in advance,
> > > > Jeff
>
> > > I don't have the references at hand, but there are also some docs on
> > > MetaLink that specifically address this exact question. Just search
> > > on 'duplicate database'.
>
> > Same file system structure? How is the backup performed? To disk?
> > Storage manager?
>
> The file structure is the same. The OS (Windows 2003) for each server
> is the same. The original backup was performed using RMAN and saved
> to tape. The database is 9.2.0.7.
>
> Thanks for your help!
> Jeff

Just FYI: I don't have much experience with 9iR2 on Windows, but there was a bug in 9i where incomplete duplications were not restartable. I'm not sure how large your DB is, or how long this process will take, but should something bomb, you may want to finish "manually" (like a traditional restore, and then switch the name with nid). Otherwise, you may have to start over (i.e. any restored datafiles will be restored again. Ugh).

Anyway, in RMAN terms:
auxiliary = your destination database
target = your source database

Depending on your storage manager, you may have to do some "setup" to restore your prod backup to "another host". For me, this has been true with NetBackup, Tivoli, and OmniBack.

The steps should be something similar to:

 1.) Audit your auxiliary database and save any info/config/etc you wish to replace
 2.) If you're using a catalog, save any stored scripts you may have for the aux db
 3.) Ensure aux db has the same UNDO tablespace names defined as target

 4.) Shut down the aux db.
 5.) Optional: rm any data, control, redo files
 6.) Choose an SCN or time to recover to
 7.) startup nomount the "aux" db
 8.) Invoke rman and run your duplicate script

rman auxiliary / target sys/pass_at_prod rcvcat rman/rman_at_rman

run
{
  allocate auxiliary channel t1 type 'sbt_tape'....;

  set until scn ...;
<or>
  sql 'alter session set NLS_DATE_FORMAT = "yyyy-mm-dd hh24:mi:ss"';   set until time '...';

  duplicate target database to <aux_db_name>   logfile GROUP 1 SIZE Nm,

          GROUP 2 SIZE Nm ...
;
}

 9.) If you're using a catalog, re-register aux db with catalog
10.) If you're using a catalog, recreate your stored scripts
11.) Unlikely: fix undo segments/in-doubt transactions
12.) Check/change global name
13.) Recreate temp table spaces
14.) Change archivelog mode?