oracle goldengate architecture

 Hello Friends,

In this post we will discuss about the oracle goldengate architecture with explanation,

so let's get started.

Oracle Goldengate supports the replication of data for various heterogeneous platforms. 

It provides support for IBM Informix and extended support for Microsoft SQL Server and MySQL. Oracle GoldenGate is  now  set for data transfer, enabling customers to replicate between on-premises and cloud environments without an extra VPN connection open.

Oracle GoldenGate Adapter for Java can enable integration with Oracle NoSQL, Apache Hadoop, Apache HDFS, Apache HBase, Apache Storm, Apache Flume, Apache Kafka, and others and allows real-time, noninvasive data streaming into big data targets 

The Goldengate replication topology will include the capture and transfer of the extracted data from the source database, 

across to the destination database.

Below are the topologies which can be used to various data transfer requirements using data replication.

Below are the Goldengate Topologies

I * Uni directional: Data is replicated in one direction from source to target

II * Bi Directional: The data flows in both direction and stays synced up between site 1 and site 2

III * Peer to Peer: Similar to Bi-directional but involves more that 2 databases which stay synced up

IV * Broadcast: Data from source is sent to multiple destinations

V * Consolidation: Data from multiple sources is delivered to one destination DB

VI * Cascading: Data from one source is sent to multiple destinations


Oracle Golden Gate Architecture For Initial Load 

Diagram Credit source Internet 


Below are the components in Goldengate architecture:

GoldenGate Components

1) Manager: The Manager is the process which starts the other Goldengate processes. This Manager process must be running on the source and target system for the configuration and starting up of all the other Goldengate processes. The  process also manages the disk space by purging the old trail files. Only one Manager Process is required for every Goldengate installation.


2) Extract: The Extract process is liable for capturing the all committed DML transactions and the DDL from Oracle Redo logs. Then Extract writes these data changes into Trail or Extract Files.

 

3)Data Pump: The Pump process which is also an extract process is optional in the Goldengate setup. This process copies the Trail files containing the data to the target system.


4) Replicate: The Replicate process is the apply process in the Goldengate configuration. This process runs at the end point of the data delivery chain on the target database. This process reads the destination trail files and applies the data changes to the target systems.


5) Trail / Extract Files: The Extract process on the source database creates trail files for consumption by the pump process for transfer to remote database or for consumption by a local replicate on the source database.


6) Checkpoint: The Extract Pump & Replicate processes use checkpoints for tracking the progress of these processes. This mechanism marks the area location up to point where the data changes have been retrieved or applied from the trail files. This is useful when processes need to recover without any loss of  data) or need to know the starting point after a failure.


7) Collector: The Collector process runs on the target system and writes the data changes from the source database in the target Trail Files known as RMTTRAIL. Before copying it to RMTTRAIL it reconstruct the files.


Follow the link to configure goldengate from oracle to oracle (Homogenous)

Follow the link to configure goldengate from sqlserver to oracle (Heterogeneous) 


Hope this post helps .


Previous
Next Post »

1 comments:

Click here for comments
Unknown
admin
January 19, 2021 at 7:28 PM ×

Good explanation

Congrats bro Unknown you got PERTAMAX...! hehehehe...
Reply
avatar