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

In answer to your questions:

1. Goldengate is only there to keep the migrated 11g copy in sync with the current 9i database. As soon as the migration is complete, it will go.
2. C is indeed a standby for B.
3. Downtime is unfortunately not possible for this exercise :(
4. Opinions are divided on this, possibly yes. However we had significant performance problems implementing the replication on 11g and the solutions are not practicable in the 9i environment, so it may not happen..
5. Yes. This switch-over is a once-off and the B instance will remain the standby for C when it goes live.

Since I cannot stop production transaction on the 9i database, I'd presumably have substitute 1) and 2) by stopping the datapump on A? I am not sure though, how to configure a pump against C that will start at the exact point where the old pump stopped in step 5..

Cheers,
Tony

On 19/09/12 11:58 AM, Mark Van de Wiel wrote:
> Tony,
>
> First a few questions:
> - Are you using GoldenGate just to replicate from 9i to 11g, or are there other purposes for which you capture the transactions?
> - Is C a standby for B (presumably so since you use "active dataguard standby" which did not exist for 9i)?
> - Are you planning downtime during the switch (or at least a read-only state for a little bit of time)?
> - Is A going away, or do you want to keep it around as a 9i backup production system?
> - will B become an active dataguard standby for C?
>
> Assuming you continue to need the GoldenGate replication environment and will at least stop transactions on A at some point I would recommend:
> 1) Stop transactions on A.
> 2) Let extract on A catch up to current and GoldenGate has several ways to find out whether you are there.
> 3) Make sure the replicats on B apply all transactions, so that these get propagated to C.
> 4) Switch primary and DR between B and C.
> 5) Configure extract on C to start as of the switch (which is NOW if the application has not started performing transactions) - otherwise it is as of the SCN of the switchover which is somewhere in the data dictionary. Configure datapump and replicats wherever (you can also do this later).
> 6) Resume processing against C.
>
> Hope this helps.
>
> Mark.
>
> On Sep 18, 2012, at 8:05 AM, 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