Configure OGG to maintain a standby database

1. Overview of a live standby configuration

In this configuration, there is an inactive Oracle GoldenGate Extract group and an inactive data pump on the live standby system. Both of those groups remain stopped until just before user applications are switched to the live standby system in a switchover or failover. When user activity moves to the standby, those groups begin capturing transactions to a local trail, where the data is stored on disk until the primary database can be used again.

2. Requirements

• Keep the standby database synchronized with the primary database.
• The primary database will be actively processing changes.If your applications permit, you can use the live standby system for reporting and queries, but not DML. If there will be active transactional applications on the live standby system that affect objects in the Oracle GoldenGate configuration, you should configure this as a active-active configuration.
• To allow for the fastest recovery time, typically you will want the database structures and data in the standby database to be identical to the primary database. However, by using GoldenGate you have the flexibility to allow differences in your primary and standby databases.
• Fast switchover from the primary database to the standby disaster recovery database for both planned and unplanned outages.
• After failover or switchover to the standby database, the database roles are reversed and it becomes the primary database. As needed, the database roles can be reversed back to their original configuration at a later time.
• After failover or switchover, changes to the standby database must be captured to allow for synchronization when the primary database is returned to the configuration.

3. Setup

First setup replication  from primary to standby which is similar to setting up basic one-way replication.

1). Primary Extract: lemp1 

GGSCI (cora) 3> view param lemp1

extract lemp1

dynamicresolution

userid gguser,password AACAAAAAAAAAAAGAWHIJOHDJJFSGVCIH,ENCRYPTKEY default

setenv (ORACLE_BASE=/u01/app/oracle)

setenv (ORACLE_SID=orcl11)

ddl include all

ddloptions addtrandata,report

ReportCount Every 10000 Records, Rate

Report at 00:30

DiscardFile /u01/app/gg/dirrpt/lemp1.dsc, Append

DiscardRollover at 02:00

ExtTrail /u01/app/gg/dirdat/l1

Table scott.*;

2). Primary Data-pump: pemp1

GGSCI (cora) 4> view param pemp1

Extract pemp1

dynamicresolution

userid gguser,password AACAAAAAAAAAAAGAWHIJOHDJJFSGVCIH,ENCRYPTKEY default

PassThru

ReportCount Every 10000 Records, Rate

Report at 00:30

DiscardFile dirrpt/PHREMP2.dsc, Append

DiscardRollover at 02:00

RmtHost 127.0.0.1, MgrPort 7901

RmtTrail /u02/app/gg/dirdat/l2

Table scott.*;

3). Primary Replicat: remp1

GGSCI (cora) 2> view param remp1

Replicat remp1

userid gguser,password gguser

dynamicresolution

AssumeTargetDefs

ddl include mapped

ddloptions report

ReportCount Every 10000 Records, Rate

Report at 00:30

DiscardFile /u02/app/gg/dirrpt/remp1.dsc, Append

DiscardRollover at 02:00

Map scott.*, Target scott.* ;

Then setup replication from standby to primary . You will configure, but not start, the replication back from the standby database to the primary database.

1). Standby Extract: lemp2 --Not include DDL replication

GGSCI (cora) 2> view param lemp2

Extract lemp2

dynamicresolution

userid gguser,password gguser

setenv (ORACLE_SID=orcl)

setenv (ORACLE_BASE=/u02/app/oracle)

ReportCount Every 10000 Records, Rate

Report at 00:30

DiscardFile dirrpt/LHREMP3.dsc, Append

DiscardRollover at 02:00

ExtTrail /u02/app/gg/dirdat/l3

Table scott.*;

2). Standby Data-pump: pemp2

GGSCI (cora) 3> view param pemp2

Extract pemp2

dynamicresolution

userid gguser,password gguser

PassThru

ReportCount Every 10000 Records, Rate

Report at 00:30

DiscardFile /u02/app/gg/dirrpt/pemp2.dsc, Append

DiscardRollover at 02:00

RmtHost 127.0.0.1, MgrPort 7801

RmtTrail /u01/app/gg/dirdat/l4

Table scott.* ;

3). Standby Replicat: remp2

GGSCI (cora) 5> view param remp2

Replicat remp2

dynamicresolution

userid gguser,password gguser

AssumeTargetDefs

ReportCount Every 10000 Records, Rate

Report at 00:30

DiscardFile /u01/app/gg/dirrpt/remp2.dsc, Append

DiscardRollover at 02:00

Map scott.*, Target scott.* ;

3. Performing a planned switchover

To keep it simple, we've divided the planned switchover steps into five parts, each with several steps. Let’s begin with Part 1:

1) Stop the application connected to the primary database.

2) After verifying there is no lag, stop the Local Extract:

GGSCI (cora) 13> lag lemp1

3) After verifying there is no lag, stop the data-pump Extract:

GGSCI (cora) 15> lag pemp1

4) After verifying there are no more records to process, stop the Replicat:

GGSCI (cora) 4> lag remp1

Now you’ve completed part 1 of the switchover process. The primary database is no longer being used by the application and the replication from the primary database to the standby database is stopped. Now you can proceed to part 2.

 

1) To begin capturing changes in preparation for the application switchover, alter the Local Extract for the standby database to begin capturing changes now and then start it:

GGSCI (cora) 5> alter lemp2,begin now

GGSCI (cora) 6> start lemp2

2) Prepare the standby database for the application and start the application connected to the standby database. In preparation, you may need to grant some SQL permissions to your application users on the standby database. Also remember to enable any triggers or cascade delete constraints you may have stopped while the standby was the replication target.

3) At this time you should perform. any maintenance required on the primary database while there are no applications connected.

After completing part 2, you should be done with your database maintenance and ready to switch the databases back to their original configuration. In order to do that, you must apply any changes made to the standby database, while it was functioning as the primary database, back to the original primary database. Those steps are shown in part 3.

1) First you need to complete any maintenance activities on the primary database. Until the maintenance is successfully completed, the standby database will act as the primary. Make sure to disable any triggers or cascade delete constraints on the primary before processing the GoldenGate changes from the standby.

2) Stop the application running against the standby database. At this time be sure to leave the Local Extract running so it can capture any remaining database transactions.

3) Start the the Replicat on the primary database to prepare to process the changes that were made on the standby database:

GGSCI (cora) 16> start remp2

4) Start the data-pump Extract on the standby to send change transactions to be processed by the Replicat on the primary:

GGSCI (cora) 11> start pemp2

In part 3 you finished your database maintenance and then processed all the changes that were made to the standby database while it was acting as the primary database. Next you need to turn off the replication from the standby database to the primary database in part 4.

1) After verifying there is no lag, stop the Local Extract on the standby database.

2) After verifying there is no lag, stop the data-pump Extract on the standby database.

3) After verifying there are no more records to process, stop the Replicat on the primary database.

Now that the replication from the standby to the primary is complete and stopped, you can proceed with restarting the original replication from the primary database to the standby database in part 5.

1) To being capturing changes in preparation for the application switchover back to the primary database, alter the Local Extract for the primary database to begin capturing changes beginning now and then start the Extract:

GGSCI (cora) 16> alter lemp1,begin now

GGSCI (cora) 17> start lemp1

2) Prepare the primary database for the application and start the application connected to the primary database. In preparation, you may need to grant some SQL permissions to your application users. Also remember to enable any triggers or cascade delete constraints you may have stopped while the primary database was the replication target.

3) Start the data-pump Extract on the primary database.

4) Start the the Replicat on the standby database.

Now you have completed Part 5 of your replication switchover process and the databases are back to their original configuration. As a result, you have minimized the downtime for your application from four hours to the minimum required to switch your application to the standby database and back.

Picture4.jpg

Picture5.jpg

Picture6.jpg

part1.jpg

part2.jpg

part3.jpg

part4.jpg

part5.jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26679417/viewspace-750114/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26679417/viewspace-750114/