"For disaster recovery" [2] is about using Oracle GoldenGate to replicate between the primary and standby database. "On disaster recovery"[1] is about running Oracle GoldenGate in a disaster recovery setup for other purposes. "On disaster recovery" usually care about how to keep Oracle GoldenGate running while failover happens in the DR setup. "For disaster recovery" usually cares about making sure the replicat keep running to make sure the standby database is synchronized with the primary database.
When To Use Oracle GoldenGate for DR
Oracle GoldenGate is used for database disaster discovery in the following situations:
- Heterogeneity : The primary database and the live standby database are in different database versions, operation systems or types/editions. The following are some examples:
* You want to create a DR database in cloud. The on-premises database in different operating systems such as Solaris Sparc and AIX. The cloud database runs on LINUX.
* You'd like to have a single Oracle 12c database to be the DR database with each of its PDB to be a DR database for a primary database.
* You want to create a DR database with a low cost database edition such as Oracle Standard Edit or use Open Source Database like MySQL Database. - Subsetting: The live standby database is a subset of the primary database. You might only want to protect some key tables from getting lost following a disaster.
- Active- Active High Availability: Instead of providing standby DB, the solution create two or multiple database all can accept new transaction operations and kept in sync. If one is down, the other one will take over the the operation. Most of DR solutions can't enable active-active replication between two or multiple databases.
What To Consider When Using Oracle GoldenGate for DR
You need to make sure Oracle GoldenGate has the backup recovery or HA setup to continuously replicating data from primary database to the standby database.
The following are the steps during the disater recovery:
- Start the extract at the primary DB
Please include EXCLUDEUSER <ggadmin> in the extract to avoid data looping later. - Create the standby DB and import data from primary DB to the standby DB.
This normally involved the import/export tools or the backup tools like Oracle RMAN. - Start the replicat at the new DB with HANDLECOLLISIOINS.
The collisions only happens if there are transactions after extract is started and before exporitng data from the old DB (between step 1 and 2)
Note: After GoldenGate 12.1.2, you can also use the start replicat with afterCSN to atCSN to avoid handling collisions. - Checke the lag and remove HANDLECOLLISIOINS after repliat catches up (no lag)
<--- Now, the standby DB should be synced up with the primary DB (Live Standby) - Setup the extract on the standby DB and replicat on the primary DB to enable replication from the new DB to the old DB. Please include EXCLUDEUSER <ggadmin> in the extract to avoid data looping.
<--- Now, *restricted* bi-directional replication is setup without CDR.
Both old and new DB can take application transactions. You just need to make sure no current update on the same table. - In case of switch over, the application can move to from the primary to the standby database. The capture in the standby database will keep tracking the transactions after the swithchover and can deliver to the old pimary DB when ready to keep the data in sync.
<--- This is DR Switchover
- Oracle GoldenGate on Disaster Recovery
- Oracle GoldenGate for Disaster Recovery
- Disaster Recovery for Oracle Database Zero Data Loss Recovery Appliance, Active Data Guard and Oracle GoldenGate
- How To Recover Integrated Replicat from a Corrupt trail or Corrupt Checkpoint (Workaround) (Doc ID 1953483.1)