Re: Dataguard role switching procedure with active GoldenGate replication - is there a best practice?

If it is a one time move I would NFS mount OGG home from B to C or copy OGG from B to C and will start same replicats on C after B switchover to C, note same checkpoint files on both replicat site. If replicat crashes it is Recoverable. The adjustment will be the rmthost parameter on the pump only.

If it is a constant requirement than I would implement two pumps one to B and the second to C, but can use the above approach as well.

The previously suggested order of making sure that extract, capture transactions ( send extract * logend, send extract getlag), make sure that pump process trail records and replicat applies until all record applied (send replicat status etc) applies in both cases.

Regards,

Guenadi Jilevski

On Tue, Sep 18, 2012 at 3:05 PM, De DBA <dedba_at_tpg.com.au> wrote:

> G'day!
>
> I've got a production database (9i) running on an old server A in the
> "Production" data centre, a new 11g database on server B in the "DR" data
> centre and an active dataguard standby on server C, which is in the
> "Production" data centre. There is a GoldenGate extract and a datapump on
> server A, and 4 GoldenGate Replicats on server B (in "DR"). The plan is to
> migrate the 9i database on server A (Production) to server B (DR) and
> perform a switch so that server C will eventually run production.
>
> The problem that now arises is that due to a change in the project the
> role switch between server B (DR, now primary) and server C (Production,
> currently standby) has to be made whilst replication with GoldenGate is
> still in place. The 4 replicats will therefore need to be moved from server
> B to server C as part of the role switch. As this is a financial system,
> and the intended future production environment, it is unacceptable to loose
> even one transaction in the process.
>
> I was thinking of stopping the datapump extract on server A, noting where
> it left off (trail file, RBA), and allowing the replicats on server B to
> finish applying all trail files that were shipped. Then create a new
> datapump extract to pump to server C, and create new replicats on server C
> that then can start applying with the first trail file they find. This
> would narrow the point of failure to only the datapump, which can be
> instructed to start exactly at the point where the original pump was
> stopped.
>
> I wonder if this scenario is anywhere near best practice, or indeed
> whether best practices for switching the GG target database over to the
> standby do exist?
>
> Cheers,
> Tony
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l