Re: backup controlfile to trace

"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 Wed Feb 21 2001 - 17:15:50 CST