Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







  GoldenGate High Availability (HA) overview tips

GoldenGate Tips by Donald BurlesonApril 17, 2015

Overview of HA for GoldenGate

The objective of this chapter is to use Oracle GoldenGate 12c two-node configuration for building high availability infrastructure to support business applications maximum availability by minimizing disruption due to system failure. Oracle customers have been implementing Oracle real application clusters (RAC) for high availability and Oracle Data Guard (DG) for disaster recovery.

The two solutions co-exist for the best continuity. RAC and DG require an advanced level of skills to implement and manage together. RAC and DG are the major components of Oracle Maximum Availability Architecture (MAA) for sites running mission critical systems and requiring a maximum level of scalability, data availability, and data protection. For applications that may compromise RAC embedded scalability and DG fast start failover, Oracle GoldenGate achieves the requirements for business continuity with a sustainable budget, operational cost, and reasonable infrastructure complexity.

The flexibility of Oracle GoldenGate advanced configuration enables the software to provide business continuity similar to RAC and DG combined using active-passive and active-active bi-directional topology architecture. However, this specific implementation is not out-of-the-box and requires a considerable level of Oracle GoldenGate and database experience in respect to the database design and applications coding.

This chapter implements Oracle GoldenGate for business continuity using similarly designed architecture for deploying:

§  Active-Passive Model for Disaster Recovery (DR)

§  Active-Active Model for High Availability (HA)

Unlike Oracle Real Application Clusters (RAC) in terms of scalability, Oracle GoldenGate does not promote the built-in scalability provided by RAC, which is

the core function of RAC to support linearly increasing transactions volume. When

scalability is an important element of the application, sufficient evaluation is necessary before deploying Oracle GoldenGate for high availability. Also, with Oracle Real Application Clusters (RAC), increasing the number of nodes delivers higher scalability. However, Oracle GoldenGate encourages the use of two-node architecture only for high-availability. This is recommended to avoid complex data conflict detection and resolutions in an active-active bi-directional topology.

For an enterprise, Oracle GoldenGate does not replace RAC or DG, rather it is implemented to complement and integrate with the Oracle clusterware and Oracle physical standby database. Refer to Chapter 12 to learn more about integrating Oracle GoldenGate with RAC and DG.

For sites running the Oracle Database Standard Edition, Oracle GoldenGate is an attractive option for implementing high availability (HA) and disaster recovery (DR). The option is cost-effective and highly suitable for in-house developed applications,

but needs to be developed from the group-up so that the applications are replication-aware. In deploying Oracle GoldenGate on bi-directional active-active topology, the challenge is to handle data conflicts which are discussed using the following:


§  Data and Applications Segmentation

§  Oracle GoldenGate Built-In Conflict Detection and Resolution (CDR)

§  Custom Conflict Detection and Resolution using PL/SQL Sub-Programs Development

§  Oracle Virtual Private Database (VPD)


The use of Oracle GoldenGate 12c for business continuity has advantages and disadvantages in using the same bi-directional topology architecture to build the foundation for a disaster recovery site and high availability on supported platforms.

When using Oracle GoldenGate for disaster recovery (DR), the major point of discussion is unsupported data types. For applications not using any of the unsupported data types, Oracle GoldenGate is an option for disaster recovery solutions. Switchover and failover from the primary system to the live standby system and vice versa is an interactive process and requires manual execution of commands or scripts.

The downtime associated with switchover and failover is very low and varies from site-to-site. The chapter has illustrated the following:

§  Planned moving of users from primary to live standby system for switchover

§  Planned moving of users back from live standby to primary system for switchover

§  Unplanned moving of users from primary to live standby system for failover

§  Unplanned moving of users back from live standby to primary system for failover

When using Oracle GoldenGate for high availability (HA), detailed analysis is carried out to evaluate Oracle GoldenGate capability of achieving the level of scalability for low-high transactions volume. When Oracle GoldenGate is deployed from the ground up, the applications become replication-aware (transparent replication) which promote Oracle GoldenGate for a high availability platform. However, deploying Oracle GoldenGate at a later stage results in the challenge of handling data conflict.  

This chapter has discussed and illustrated techniques of handling data conflicts using:

§  Data and Applications Segmentation

§  Oracle GoldenGate Built-In Conflict Detection and Resolution (CDR)

§  Develop PL/SQL Sub-Programs and implement callout using SQLEXEC

§  Oracle Virtual Private Database (VPD) for total segmentation

Throughout the chapter, a two-node bi-directional topology architecture is demonstrated. A three-node topology architecture, multi-master brings challenges and should be

carefully qualified for disaster recovery and high availability solutions. Oracle GoldenGate considerations, in respect of disaster recovery and high availability, are discussed to lead to a sound decision and minimize the impact of post-deployment changes.

The chapter also compared Oracle GoldenGate with Oracle Real Application Clusters (RAC) and Oracle Data Guard (DG). It was made clear, for an enterprise, Oracle GoldenGate complements RAC and DG rather than replaces them.

GoldenGate High Availability

Oracle High Availability has been always associated with Oracle Real Application Clusters (RAC), where within the same data center, multiple tightly coupled servers (nodes) access the same database. Another advanced architecture of RAC is Extended RAC, where nodes are loosely coupled and spread across two or more data centers. Figure 5-12 compares the high availability of Oracle GoldenGate and Extended RAC.

The upper part of Figure 5-12 is Oracle GoldenGate configured using an active-active

bi-directional topology model. Over the TCP/IP network, data flows from the site A (node-1) to site B (node-2) and vice versa. The self-evident advantage of this solution is the unlimited distance between node-1 and node-2. The drawback is the chance of scalability and data conflict handling.

However, because the data is delivered in canonical format for a well-developed application, node-1 and node-2 may use different platforms. For example node-1 is Oracle Database 11g on Oracle Solaris while node-2 is Oracle Database 11g on Oracle Linux. Avoid heterogeneous database architecture for a high availability solution, unless the applications developed to support all database types transparently.   

The lower part of Figure 5-12 shows Oracle Extended RAC. The databases are mirrored using dense wavelength division multiplexing (DWDM) over a dark fiber link. This enables always in-sync copies of the database. The self-evident advantage is out-of-box scalability and high availability. The drawback is the distance limitation between site A and site B for up to 100 kilometers and cost-factor.



                 Figure 5-12: Comparison of 2-Node Oracle GoldenGate and Extended RAC


When using Oracle GoldenGate to implement a high availability platform, it is configured as an active-active bi-directional topology model. The source system

(node-1) and target system (node-2) are available for user connections. Users may explicitly connect to either system based on predetermined attributes such as location, range of TCP/IP address, built-in application context, etc.

Implicit connections will be based on database and/or system workload. Users requests are routed to the system with minimal workload. This provides connection time workload evaluation to distribute database sessions across both systems. Figure 5-12 shows an implicit form of handling users connections. The database load balancer evaluates the preferred database, which is the database with lesser workload. Then, send the request to the application server which has its own HTTP load balancer. For more details regarding a high availability load balancer, refer to Figure 5-2.

                              Figure 5-13: Load Balancing on Bi-Directional Topology


Applications running on Windows such as Oracle for .NET employ Oracle SQLNET to connect to the database. Whereas Java desktop applications employs JDBC drivers to connect to the database. For this type of applications, HTTP Servers are eliminated, the client applications establish stateful types of database connections.

Oracle GoldenGate 12c

The above is an excerpt from the upcoming 12c book Oracle GoldenGate 12c: A Hands-on Guide to Data Replication & Integration using Oracle & SQL Server.

Hit Counter


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster