Configuration Options in Oracle GoldenGate

As a DBA who designs and implements replication solutions based on Oracle GoldenGate, you are probably aware that this software could be used in a number of diverse scenarios. It’s a very flexible and versatile platform with a broad spectrum of applications ranging from one-way replication and creating standby databases to load balancing, data distribution, and updating conventional data warehouses and big-data-based repositories. In fact, this software is indispensable for DBA teams whenever there is a need to build a non-trivial solution where replication — in one form or the other — is a major component. Let’s take a look at a few features that make this product such a success story amongst Fortune 500 companies spanning various verticals – retail, utilities, banking, finance, telecom, and more.

Oracle GoldenGate has a modular architecture that consists of the following discrete components, both artifacts and processes:

• Initial loading process
• Extract process
• Replicate process
• Collector process
• Trail files
• Data pumps

These components can be designed, configured, tested, and deployed in distinct patterns or topologies. Each topology is a configuration of Oracle GoldenGate and is geared toward solving specific business challenges. To learn more about the different topologies, download the whitepaper: GoldenGate A Solution to Issue of Space and Latency

Let us take a look at the various topologies or configurations of the product. From here onward we will use these two terms interchangeably.

Unidirectional (Active to Passive)

The unidirectional configuration is one of the most common and basic Oracle GoldenGate configurations. It’s used in scenarios where there is a need to create a separate database for reporting, querying, or testing using live data in real time. The essential benefit is that users are able to run reports, query data or test applications on separate databases, keeping the load off of production database servers.

Another business scenario in this context is data migration from one database to another. It is termed as unidirectional as it involves the flow of data in one direction only — from the source (production database) to the target database. Data can be quickly replicated on an as-needed and when-required basis.

Bidirectional (Active to Active)

Imagine a scenario where an Oracle database needs to be updated but the underlying business functionality is just too critical to be put on hold for the duration of the update.

The solution is implementing Oracle GoldenGate in a bidirectional configuration, which enables replication and synchronization between two systems — the source and the target. In other words, the underlying application will be shifted from the primary database (source) to the secondary system (target) for the duration of the update. After the update is over the application will revert to the primary database, after it’s synchronized with the secondary database.

Another restricted application of this configuration is load balancing between two servers. This is known as a restricted application because the real benefits and scalability of load balancing can be achieved in a peer-to-peer (multi-master) configuration, as we will see below.

Peer to Peer (Multi-master)

A peer-to-peer configuration enables setting up and replicating data amongst more than one server with a view to achieve load balancing amongst the databases.

One to Many (Broadcast)

Imagine an office in Los Angeles wants to update corporate data across its other locations in New York, London, and Hong Kong. The solution is to implement Oracle GoldenGate in a broadcast configuration where the system is designed to replicate data from a single source to multiple destinations.

Many to One (Consolidation)

A many-to-one topology is where data from multiple sources is collected and channeled into a single target. This configuration is significant as it’s applied for updating external data mining systems, both conventional and big-data-based.

It’s also important to point out that with Oracle GoldenGate it’s possible to replicate either the entire database or just a granular unit — a schema or a single table. The strength of Oracle GoldenGate lies in the fact that each of the given topologies (or configurations) may fulfill a number of diverse scenarios.

Oracle GoldenGate provides a single platform that can extract data to external mining systems with a low latency and minimal impact on existing transactions. There are many ways to configure GoldenGate so download our white paper, for further insights into this platform.