In the last post, we introduced the Oracle’s GoldenGate software primarily used for effective and efficient data transfer from one database to another. That post also let you discover the value and benefits GoldenGate brings to the businesses looking for the ways for smooth data transfer and integration across diverse databases.
In this post, we will look the underlying data replication technology of GoldenGate more closely and exploring the ways available for its configuration with existing infrastructures.
The Technology Overview of GoldenGate
GoldenGate is leveraged on the transaction log shipping as well as log-apply architecture. The architecture is composed of elements that do the data transfer tasks. It is significant to note that we intentionally didn’t mention Redo Log here and used only the word “Log”. This is because GoldenGate has not been designed to work just with Oracle database where the transaction logs are named as Redo Logs. Hence, if you are using GoldenGate with database of Oracle, the term Redo Logs will be used but for other databases, the term will be different.
One of the prime advantages of the GoldenGate technology is that it provides enough flexibility and can be applied in a lot of ways to address various kinds of requirements.
All the available options for configuration hold benefits in their own way. Therefore, using each configuration is subject to the business needs and differ from one business to another.
Following the most commonly used system configurations supported by GoldenGate.
· One-to-One (called Unidirectional)
· One-to-Many (called Broadcast)
· Many-to-One (called Consolidation)
· Bi-Directional (called Active-Active)
· Multimaster (called Peer-to-Peer)
· Cascading Data Marts
The Logical Architecture of GoldenGate
The architecture of GoldenGate consists of the following major components:
1. Manager
It is the process that initiates the GoldenGate processes.
It must run both on the target and source system for configuration and must start other processes of GoldenGate.
It also assigns the disk space by removing the old trails and extract files.
The Manager process is needed for each GoldenGate installation.
2. Extract
The extract process is based on data extraction, also called data capture.
Extract is a process configured to operate against the source mining database.
This process is designed to capture the assigned data modeling language transactions and the data definition language from the Oracle Redo Logs. Extract process writes the data changes into extract files and trails.
3. Trail
A trail is a set of files placed on the disk where GoldenGate saves the captured changes, supporting the continuous replication and extraction of these database changes.
4. Replicat
Replicat process transmits data to the target database, after reading the trial on the target database, rebuilds the DML or DDL operations, and uses them at target database.
5. Checkpoint
This process determines the sites of data changes that have been applied or retrieved from the trail files. It is beneficial when the processes must recover without data loss or determine the starting point after any failure.
We hope this post must have helped you know the underlying technology of GoldenGate and its logical infrastructure mechanism. In the next post, we shall reveal some more pros and cons of the software that you should be aware of before its deployment.
