9 Configuring Oracle GoldenGate

Oracle GoldenGate delivers low-impact, real-time data acquisition, distribution, and delivery across both homogeneous and heterogeneous systems. Oracle GoldenGate enables cost-effective and low-impact real-time data integration and continuous availability solutions across a wide variety of use cases. Oracle GoldenGate offers close integration with Oracle technologies and applications, support for additional heterogeneous systems, and improved performance.

This chapter contains the following topics:

9.1 Oracle GoldenGate Overview

Oracle GoldenGate captures primary database changes by reading redo records from a source database online redo log file, transforming those records into a platform independent trail file format, and transmitting the trail file to a target database(s). Oracle GoldenGate maintains a logical replica by converting the trail file into SQL and applying SQL to a target database. A target database is open read/write while synchronization occurs. Additional Oracle GoldenGate information can be found at


Oracle GoldenGate is ideally used where its flexibility can address advanced requirements not addressed by other MAA features. Oracle GoldenGate is an important element in the MAA architecture, useful for the following purposes:

  • Active-Active multi-master configurations used for data availability and to scale performance. An important consideration for such configurations is the ability to manage update conflicts either by avoiding them or by implementing a process for conflict detection and resolution.

  • Offload operational reporting when read/write access to the reporting instance is required.

  • Near zero downtime (one-way replication) or zero downtime (bi-directional replication) for planned maintenance tasks, including:

    • Database upgrades

    • Application upgrades that modify back-end database objects (requires the user to implement transformations to map old and new versions.

    • Database consolidation

    • Database and platform migrations

9.1.1 Oracle GoldenGate and Oracle RAC

Oracle Real Application Clusters (Oracle RAC) enables multiple instances that are linked by an interconnect to share access to an Oracle database. In an Oracle RAC environment, Oracle Database runs on two or more systems in a cluster while concurrently accessing a single shared database. The result is a single database system that spans multiple hardware systems, enabling Oracle RAC to provide high availability and redundancy during failures in the cluster. Oracle GoldenGate is integrated with Oracle RAC and Cluster Ready Services (CRS) using the Oracle Grid Infrastructure Agent such that during cluster node failures, GoldenGate will automatically restart on a surviving node.

See Also:

9.1.2 Oracle GoldenGate and Oracle Data Guard/Oracle Active Data Guard

Oracle GoldenGate is Oracle's strategic logical replication product. Oracle Data Guard is Oracle's strategic physical replication product focused on data protection and data availability, and is the standard MAA recommendation for such purposes because of the advantages it offers over logical replication. Oracle Data Guard is also commonly used in place of storage-remote mirroring or host-based mirroring solutions for disaster protection. Oracle Data Guard also minimizes planned downtime by supporting database rolling upgrades, select migrations (for example, Windows to Linux), data center moves, and other types of planned maintenance. Oracle Active Data Guard, an extension to Oracle Data Guard, is the simplest, fastest, most efficient method of maintaining a synchronized physical replica of a source database open read-only for offloading read-only workload and backups. For a detailed discussion of Data Guard advantages for data protection, see the Product Technical Brief, "Oracle Active Data Guard and Oracle GoldenGate" available from the GoldenGate link at


Oracle GoldenGate is often used in Data Guard configurations in a complementary manner. Oracle GoldenGate is integrated with Data Guard using the Oracle Grid Infrastructure Agent, so that during a Data Guard role transition (switchover or failover) the GoldenGate processes will restart automatically on the primary database. The Data Guard protection mode can be either MaxAvailability/MaxProtection (zero data loss) or MaxPerformance (data loss).

See Also:

Oracle Grid Infrastructure Downloads web page for additional information on the Oracle Grid Infrastructure Agent at http://www.oracle.com/technetwork/database/database-technologies/clusterware/downloads/index.html

9.1.3 Oracle GoldenGate and Edition-Based Redefinition

Edition-based redefinition is a capability implemented entirely within Oracle Database that enables database objects that implement the back end of an application to be patched or upgraded without interrupting the availability of the application. Edition-based redefinition enables customers to implement application upgrades online with zero database downtime. Edition-based redefinition requires Oracle Database 11g Release 2, and it requires application changes; an application must be made editionable to upgrade online.

Oracle GoldenGate can also be used for online application upgrades. The application itself does not need to be modified to implement an upgrade, but the administrator must have sufficient knowledge of the differences between old and new versions of the application to implement mapping between versions using Oracle GoldenGate. User control over the application, and user preference for the second major distinction between these technologies determines which approach makes the most sense to achieve a zero downtime application upgrade.

The second major difference between these technologies is that edition-based redefinition uses only the single database that ordinarily supports the application. Oracle GoldenGate uses a second synchronized database to execute the upgrade.

  • Using edition-based redefinition, the old version of the application is in the old edition and the new version of the application is in the new edition - both within the same database; the edition is the isolation mechanism. Data that is represented the same in the old and the new versions of the application is represented only once in table columns used by both versions; only data that is represented differently in the two application versions must exist twice. Synchronization is needed, therefore, only for that typically small proportion of the total data that differs between the two versions. Because a cross edition trigger fires within a transaction, potential conflicts between the old and the new representations are prevented before they can be committed, and there is no need for conflict-resolution.

  • Using Oracle GoldenGate, the old version of the application runs on the original database and the new version of the application runs on a second database; the second database is the isolation mechanism. All data - both that which is represented the same in the old and the new versions of the application and that which is represented differently in the two application versions must exist twice. Synchronization is needed, therefore, for all the data. The synchronization is implemented using code that intervenes in the replay mechanism for the SQL that is constructed by mining the redo logs. It is, therefore, non-transactional; and conflicts between the old and the new representations cannot be prevented. Rather, conflict-resolution must be implemented as an explicit, post-processing step.

9.2 Oracle GoldenGate Configuration Best Practices

There are several best practices for configuring GoldenGate Extract, Data pump and Replicat for optimal performance and High Availability to reduce increased latencies caused by downtime of GoldenGate processes, including the following:

9.2.1 Oracle GoldenGate Integrated Extract and Integrated Replicat

With Oracle GoldenGate version 12.1.2, Replicat can now operate in integrated mode for improved scalability within Oracle target environments. The apply processing functionality within the Oracle database is leveraged to automatically handle referential integrity and data description language (DDL) so that the operations are applied in the correct order. Extract can also be used in integrated capture mode with an Oracle database, introduced with Oracle GoldenGate version 11.2.1. Extract integrates with an Oracle database log mining server to receive change data from the database in the form of logical change records (LCR). Extract can be configured to capture from a local or downstream mining database. Because integrated capture is fully integrated with the database, no additional setup is required to work with Oracle RAC, ASM, TDE, and data compression which greatly simplify setup without sacrificing performance.

The latest version of Oracle GoldenGate can be downloaded from My Oracle Support, Patches and Updates.

To make use of Integrated Extract you must use database release or later. The specific patch numbers required for are listed in My Oracle Support node 1557031.1. Integrated capture mode Extract can also be used to capture changes from Oracle versions starting with with downstream mining using an or higher, mining database.

To make use of Integrated Replicat use database release of or later.

9.2.2 Use of a Clustered File System

Using a clustered file system is fundamental to the continuing availability of Oracle GoldenGate checkpoint and trail files in the event of a node failure. Ensuring the availability of the checkpoint files is essential to ensure that, after a failure occurs, the Extract process can continue mining from the last known archived redo log file position and Replicat processes can start applying from the same trail file position before a failure occurred. Using Oracle Database Filesystem (DBFS) or Oracle Automatic Storage Management Cluster File System (Oracle ACFS) allows a surviving database or ASM instance to be the source of an Extract process or destination for the Replicat processes.

Best practices for configuring DBFS or Oracle ACFS for use with Oracle GoldenGate are described in each of the following references.


The best practices provided in the following documents apply to all supported Oracle GoldenGate platforms, including Oracle Exadata Database Machine.

See Also:

MAA white papers "Oracle GoldenGate on Oracle Exadata Database Machine Configuration" at http://www.oracle.com/technetwork/database/features/availability/maa-wp-gg-oracledbm-128760.pdf and "Oracle GoldenGate With Oracle Real Application Clusters Configuration" at http://www.oracle.com/technetwork/database/features/availability/maa-goldengate-rac-2007111.pdf for DBFS configuration recommendations

9.3 Oracle GoldenGate Operational Best Practices

See the following documents for more information about Oracle GoldenGate management and operational Best Practices: