Re: Help needed making a DB copy

"Vince Laurent" <eAddict_at_yahoo.com> wrote in message news:e30h50hhk60hvvditjkpl7lmh07pj2fhi5_at_4ax.com...
> the stopdb script does a shutdown immediate:

I thought you said it was called "stopsap" in an earlier reply?

There are a number of niggling inconsistencies like this in your posts which make it difficult to advise properly. Such as the fact that you originally wrote:

"6. On target system: startup mount
@tracefile"

Point being, you couldn't possibly have started up mount, because you wouldn't have had control files, and would thus only ever be in NOMOUNT state. You could perhaps have issued that command in error, and had the instance fall over in nomount state, but the error is not mentioned by you. Or it could just be a typo on your part. It could also be that you really did say startup MOUNT, and got away with it because you actually copied the control files from your source to the target (which you shouldn't be doing). But that's a handful of options, which I can't guess about as to which is the right one. What's more, the first line of the tracefile script is "startup nomount", and if you are already in the nomount state when you run it, then you get lots of errors, and the control file isn't re-created successfully. You could, of course, have edited out that line from the tracefile script and controlled the startup procedure yourself, but then that brings me back to the point that your original post doesn't contain *all* the details, and therefore makes diagnosis very difficult.

> connect / as sysdba;
> alter system switch logfile;
> connect / as sysdba;
> shutdown immediate;

This is a script you've knocked up yourself? (And can thus modify). Or one supplied by a vendor (and thus can't be touched)?

If it is the former, then get rid of the switch logfile command. It's completely unnecessary. Forcing a log switch will cause a checkpoint to be issued. But that's exactly what a shutdown immediate on its own does anyway.

Reviewing your original post, I would just suggest the following:

1. Alter database backup controlfile to trace resetlogs;
2. Shutdown immediate;
3. cp /source/*.dbf /dest/
4. Edit tracefile to change SID, specify new directories and file locations.
5. cp O_H/dbs/initSOURCE.ora O_H/dbs/initDEST.ora
6. In the initDEST.ora, change db_name and control_files.
7. If you've got O/S authentication for privileged users working for the original database, make sure that remote_login_passwordfile=NONE in the new init.ora. Otherwise copy and rename your existing password file, and make sure the parameter is set to EXCLUSIVE.
8. sqlplus "/ as sysdba"
9. @tracefile

Actually, I'd suggest cloning the database first and worrying about changing its name as a second, completely separate step. But whatever.

Regards
HJR
>
> HTH and thanks,
> Vince
>
> On Thu, 18 Mar 2004 01:36:28 +1100, "Howard J. Rogers"
> <hjr_at_dizwell.com> wrote:
> >
> >"Vince Laurent" <eAddict_at_yahoo.com> wrote in message
> >news:n5og50h8497qa07f1072fjfuquhgl6l1b2_at_4ax.com...
> >> On 16 Mar 2004 23:38:05 -0800, srivenu_at_hotmail.com (srivenu) wrote:
> >>
> >> >How did you shutdown the database ?
> >>
> >> Stopsap - which does a shutdown command.
> >
> >Uh huh.
> >
> >> Why would I need to give log files if the database was shut down
> >> cleanly?
> >
> >The command you issued sounds to me like a SAP command, not an Oracle
one.
> >And although you say it "does a shutdown", what sort of shutdown does it
do?
> >What's to stop "stopsap" from issuing a "shutdown abort" under the hood?
> >
> >So your question is spot on. It's the assumption that your database *was*
> >shutdown cleanly that I'd question.
> --------------------------------------
> Come race with us!
> www.mgpmrc.org
Received on Wed Mar 17 2004 - 14:48:19 CST