Re: re-build physical standby in DG setup

joel garry wrote:
> EdStevens wrote:
> > Subject: re-build physical standby in DG setup
> >
> > Platform: Oracle 10.2.0.1.0 on Solaris 10
> >
> > DataGuard configuration with a physical standby database. Through an
> > unfortunate set of circumstances, a couple of archivelog files didn't
> > get shipped, then got deleted from the primary site. (yes, I'm the
> > guilty party) (And when I asked the server admin guys if they could
> > restore the archivelog files from a server level backup, they
> > discovered that *their* backup procedure had been failing!)
>
> This is why I'm paranoid about backing up archive logs multiple times,
> and not deleting them for at least 3 days (ie, log shipping breaks
> Friday night of a 3 day weekend, Tuesday morning I can still suck from
> several online backups).
>
> >
> > As I understand, that leaves the standby unable to complete it's
> > recovery, so I need to rebuild it almost from scratch. I say
> > 'almost' because, as I read the chapter on creating a physical
> > standby in the DataGuard Concepts and Admin manual, it appears that
> > several of the steps that were done on the initial setup are still good
> > and can be bypassed for this exercise. Here's how I see this shaking
> > out. Please tell me if I'm getting ready to dig the hole even
> > deeper, if there's an easier way out, or if I'm on the right track
> > but need to consider a few more items.
> >
> > Following the setup steps in the doc, I should be able to bypass
> > everything dealing with creating the primary database. It was/is up,
> > and the only thing I've done is stop archive shipping, to prevent
> > filling up the recovery area target on the standby.
> >
> > On the standby, comments on each step:
> >
> > 3.2.1 - Create Backup Copy of the Primary Database datafiles.
> > (yes, use rman to backup datafiles. This will need to be a hot backup.
> > Just the files listed in DBA_DATA_FILES? Include the SYSTEM
> > tablespace?)
>
> Yes, everything. I'm jealous that 10 doesn't require everything to be
> in the exact same place :-)
>
> >
> > 3.2.2 - Create Control file for standby
> > (it says "if the backup procedure required a shutdown of the primary
> > ....". I would think I could skip this and go with the existing
> > control file of the standby, but am unsure of its record of archive
> > sequences)
>
> Only if you have an unbroken log sequence. You don't. You need a new
> controlfile for standby. I think (there may be something in 10g I
> don't know about, but I don't see any relevant new features). But it's
> easy enough
> http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14239/rcmbackp.htm#sthref2283
>
> >
> > 3.2.3 - Prepare initialization parameter file for the standby
> > (again, I should be able to go with the spfile that is already in
> > place)
> >
> > 3.2.4 - copy files from the primary to the standby
> > (yes to the backup data files, but no to the control file and parm
> > file)
> >
> > 3.2.5 - Set up the environment to support the standby database
> > (already there)
>
> OK, but for standby controlfile.
>
> >
> > 3.2.6 - start the physical standby
> > -- startup mount
> > -- alter database recover managed standby database disconnect from
> > session;
> > (yes)
> >
> > (extra item: restart log shipping on the primary)
> >
> > 3.2.7 - verify physical standby is performing properly
> > (run log switches, examine results --- yes)
> >
> >
> > If this is essentially correct, I would also think I can simply delete
> > a bunch of now obsolete archivelogs, followed by rman crosscheck and
> > delete obsolete on the primary. What of archivelog cleanup on the
> > standby, where the db is not open?
>
> Once they are applied, no problem. I use the same paranoid deletion on
> the standby as the primary, but that is generally overkill that I
> rationalize as something I won't have to change if it becomes primary.
> Although, I've seen flaky situations where I've needed to redo the
> restore and have been glad those arcs hadn't been deleted yet. I can't
> imagine a scenario where that would make sense beyond a few days after
> the restore, though. (I had one special situation that took a week to
> catch up).
>
> >
> > Anything I'm overlooking or failed to consider?
>
> jg
> --
> @home.com is bogus.
> http://www.scaryplace.com/ScaryPlace.html

Joel,

Thanks for the reply. And the good pointers. Sounds like I'm on the right track.

Good point about the control file. I was concerned that if I depended on the current one with the standby, it would still try to recover through the break in the redo stream. And the pointer to the Appendix in the DG Admin is very helpful. Thanks again. Received on Thu Jul 20 2006 - 15:14:42 CDT