Re: re-build physical standby in DG setup

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