Oracle GoldenGate Concepts and Architecture

Oracle GoldenGate Concepts and Architecture

Oracle GoldenGate supports the replication of data across various heterogeneous platforms. The GoldenGate replication topology includes 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 fulfill various data transfer requirements using data replication.

  Ø  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 site A and site B

  Ø  Peer to Peer: Similar to Bi-directional but involves more that 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 Logical Architecture

The Oracle Golden Gate architecture consists of the following components:

  v  GoldenGate Components

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

  Ø  Extract: The Extract process 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 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.

  Ø  Replicat: The Replicat 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.

  Ø  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.

  Ø  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 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 reassembles the files.

Happy Learning 😉

(source: Gavin Soorma & Vitalsoftech)