ORACLE GOLDENGATE ARCHITECTURE

Oracle Golden Gate is a tool which supports the replication of data across various heterogeneous platforms like Oracle, DB2, SQL Server, MySQL etc.

It supports different topologies shown in the Figure 1 which can be used to fulfill various data transfer requirements using data replication.

 Figure 1 Oracle Golden Gate Supported Topologies.

• Uni-directional: Data is replicated in one direction from source to target.
• Bi-Directional: The data flows in both direction and stays synced up between Source and Target sites. 
• Peer to Peer: Similar to Bi-directional but involves more than 2 databases which stay synced up.
• Broadcast: Data from source is sent to multiple destinations.
• Consolidation: Data from multiple sources is delivered to one destination DB.
• Cascading: Data from one source is sent to multiple destinations.

Oracle Golden Gate Architecture

 Figure 2 Oracle Golden Gate Architecture

Oracle Golden Gate Architecture is composed of the following Components:

1. Manager.
2. Extract.
3. Data pump.
4. Replicat.
5. Trails or extract.
6. Checkpoints.
7. Collector.

Manager

•   The Manager process must be running on both the sides (source as well as target systems).

•      It performs a number of functions including 
• Monitoring and starting other Golden Gate processes. 
•  Manages the disk space by purging the old trail files and also reporting.

•     Only one Manager Process is required for every Golden gate installation.

 Extract

•  The Extract process is the data capturing mechanism of Golden Gate.
•  It is responsible for capturing the committed DML transactions and the DDL from Oracle Redo logs.
•  Then Extract writes these data changes into Trail or Extract Files. 

Data Pumps

• Data Pumps are secondary extract mechanisms which exist in the source configuration.
• When Data Pump is configured,
• The Primary Extract process will write to the Local Trail and then this trail is read by the Data Pump and data is sent over the network to Remote Trails on the target system.

• Data Pump can also be useful in the following cases,
• When we are doing complex filtering and transformation of data.
• When we are consolidating data from many sources to a central target.

Replicat

• The Replicat process is the apply process in the Golden gate configuration.
• The Replicat process runs on the target system and reads transactional data changes as well as DDL changes and replicates then to the target database.
• Like the Extract process, the Replicat process can also be configured for Initial Load as well as Change Synchronization.

Trails

• Trails are series of files that Golden Gate temporarily stores on disks and these files are written to and read from by the Extract and Replicat processes.
• Depending on the configuration chosen, these trail files can exist on the source as well as on the target systems. If it exists on the local system, it will be known as an Extract Trail or if it exists on the target system it will be known as a Remote Trail.

Checkpoint

• The Extract Pump & Replicat processes use checkpoints for tracking the progress of these processes.
• This mechanism marks the 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 data loss) or need to know the starting point after a failure.

Collector

• The Collector is a background process which runs on the target system and is started automatically by the Manager (Dynamic Collector) or it can be configured to start manually (Static Collector).
• It receives extracted data changes that are sent via TCP/IP and writes then to the trail files from where they are processed by the Replicat process.