Re: backup controlfile to trace

Thanks for the reply. I got everything up and running. I'll check out that script.
Thanks again.

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:b5Yk6.11$kC2.2419_at_inet16.us.oracle.com...
>
> "Fender" <nospam.efender_at_ix.netcom.com> wrote in message
> news:9718oe$112$1_at_slb0.atl.mindspring.net...
> > I need some detailed help on creating a copy of a database. We made a
 cold
> > backup last night. Currently, we are restoring the datafiles, control
 files
> > and redo logs to a new location. We want to setup a test environment
> > without creating the tablespaces, datafiles and doing an export/import.
> > I've done an alter database backup controlfile to trace on the live
> > database. The backup controlfile to trace was not done immediately
 before
> > or after the shutdown for the cold backup. Does this matter?
>
>
> Not at all. When you run the trace file to create the new controlfile,
 the
> paths and so on that it contains allows the system to inspect all the
> datafiles and log files, retrieve the highest SCN found, and place that in
> the header of the new control file. That then becomes the point to which
> everything else will be synchronised when the 'recover database' command
 is
> issued (also as part of the trace script). So the backup time of the
> datafiles is irrelevant -as is the question of whether or not they were
> backed up hot or cold (though cold is easier, I guess).
>
> >Can I change
> > the database name, or must it stay the same?
>
> Yes. The line 'create controlfile reuse 'BLAH' noresetlogs' must be
 changed
> to 'create control file SET 'BLAH2' resetlogs'. You'll also need to
 adjust
> the 'alter database open' line in the trace file to read 'alter database
> open resetlogs'.
>
> >Should I use the current redo
> > logs from the live DB and let the new database roll forward, or use the
 redo
> > logs that were backed up?
>
> Makes no odds. It will cope whatever method you use -provided that the
 redo
> logs are copied across when the original database is cold.
>
> Can I change the database to noarchivelog mode at
> > this time, since this is just for testing purposes?
>
> You could do, but if I were you, I'd take it a step at a time, and change
> things bit by bit only when the previous step has worked properly. My
> cloning script ( http://www.geocities.com/hjroz2000/clonedatabase.txt )
 does
> that -it clones the thing first using the same Instance and Database
 names,
> then it shows how to change the Instance name, then the Database name gets
> changed. Only when that's all finished would I then take the thing out of
> archivelog mode. On courses, I've been asked to demo it being done all in
> one hit, and it can be done -but there's a lot to hold in mind when you
 take
> that approach.
>
> > I've already created an new init<sid>.ora and changed the names of the
> > control files and set archive to false.
>
> Potentially disastrous! Setting LOG_ARCHIVE_START to false means you've
> switched ARCH off. It doesn't take the database out of archivelog
 mode -so
> you risk hanging the new database before you even start.
>
> Don't forget to change the path names in the trace file, too. And,
 assuming
> you take my advice and take the thing out of archivelog mode only after
 it's
> been properly created, make sure you change the log_archive_dest
 parameters
> in the cloned init.ora, otherwise you risk generating archives in your
> production archiving directory -and that can get very messy.
>
> Regards
> HJR
>
>
>
> >
> > Thanks for any help,
> >
> > Eric
> >
> >
>
>
Received on Mon Feb 26 2001 - 10:36:39 CST