Re: standby db problems

clueless wrote:
>
> Hi gang,
> I have created a non-managed oracle standby database in the following
> manner:
>
> from PRODUCTION
> 1) ran 'alter database create standby controlfile as blah...'
> 2) ran 'alter system archive log current'
> 3) shutdown normal
> 4) moved all datafiles, then init.ora, and archived redo logs over to
> standby host

You should take the backup of primary *before* you create the standby controlfile. The way you've done it, all of your datafiles will be *newer* (i.e. have a more recent SCN) than your backup controlfile. I've never tried that, but I'm going to assume Oracle won't like it one bit. The documentation is pretty clear on the steps - first take a full backup (hot or cold, doesn't matter), then create the stby controlfile.

> 6) moved and renamed (is this a problem) the standby control file to the
> correct location

This is fine (renaming the stby ctlfile is no biggie as long as the standby init.ora matches the new name).

> 7) started up new instance (stanby instance)
> 8) ran 'startup nomount' on new db: success
> 9) ran 'alter database mount standby database': success
> 10) ran 'alter database recover standby database'
> I get this error:
> ORA-00279: change 76601141 generated at 04/01/2002 12:01:45 needed for
> thread 1
> ORA-00289: suggestion :
> D:\ORACLE\ORADATA\CISPROD\LOG\ARCHIVE\CISPRODT001S27021.arc
> ORA-00280: change 76601141 for thread 1 is in sequence #27021
> This archived redo log was manually shipped over to the standby location
> in step 4. I am assuming that in order for the standby instance to be
> capable of 'reading' this archived redo log it has to be shipped by the
> archiver process. Is this correct?

No - the standby is capable of recovery using any valid archive file from primary, no matter how it got to the standby site (automatic, ftp, sneakernet, whatever). The difference is basically one of convenience (automatic vs manual).

> If so is there a way of forcing the read or the arch redo log?

Sure, just feed it the fully qualified name of the file in the scenario above. In other words, first thing you want to do is to refresh your standby controlfile (the Standby Database manual is your friend here, but basically you create a new stby ctlfile, shutdown the standby, copy the stby ctlfile to the standby, and restart the stby). Then do your 'recover standby database' (you may want 'recover automatic standby database until cancel') and feed it the archives since your backup.

You started by saying this was a non-managed standby. Any particular reason you don't want it to be managed? It does tend to make life simpler.

Regards,
Sean Received on Thu Apr 04 2002 - 10:38:35 CST