Path: news.easynews.com!easynews!news-out.cwix.com!newsfeed.cwix.com!newsfeed1.cidera.com!Cidera!nntp.magma.ca!news!not-for-mail From: "clueless" Newsgroups: comp.databases.oracle.server References: <3CAC8195.DB0C65E4@BACKSIESearthlink.net> Subject: Re: standby db problems Lines: 72 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Thu, 04 Apr 2002 18:38:48 GMT NNTP-Posting-Host: 209.217.120.164 X-Trace: news 1017945528 209.217.120.164 (Thu, 04 Apr 2002 13:38:48 EST) NNTP-Posting-Date: Thu, 04 Apr 2002 13:38:48 EST Organization: Magma Communications Ltd. Xref: easynews comp.databases.oracle.server:142069 X-Received-Date: Thu, 04 Apr 2002 11:39:30 MST (news.easynews.com) Yeah, I finally figured that one out... thanks Sean. "Sean M" wrote in message news:3CAC8195.DB0C65E4@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