Re: standby db problems

Yeah, I finally figured that one out...

thanks Sean.

"Sean M" <smckeownNO_at_BACKSIESearthlink.net> wrote in message news:3CAC8195.DB0C65E4_at_BACKSIESearthlink.net...
> 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 - 12:38:48 CST