Skip links

General understanding of Oracle GoldenGate Hubs

Oracle GoldenGate Hubs are a thing!  A thing that many organizations are looking to implement and help with the management of Oracle GoldenGate.  They are created for centralizing the management of an environment, but also used to help define more robust architecture for data movement.  With the rise of Oracle GoldenGate Hubs, this has lead to deeper discussions on how placing hubs throughout an architecture can create a mesh of data flows – also known as “Data Mesh” architectures.  Before you can actually implement a “data mesh” architecture, a thorough understanding of what a “hub” is required.  

So what makes up an Oracle GoldenGate “Hub”?

Oracle GoldenGate “hub” is a single host or a single cluster on a network where Oracle GoldenGate is running from and performing remote capture and apply processes.  In a simple Oracle-to-Oracle replication stream, a “hub” would consist of:

  • Oracle GoldenGate Home (OGG_HOME (Microservices))
  • Oracle GoldenGate Deployment Home (OGG_DEPLOYMENT_HOME)
  • Nginx Reverse Proxy
  • Oracle Database Instant Client for Oracle 19c (ORACLE_HOME) 

In many cases where a “hub” would be used, you would not be using a homogenous replication; meaning that an Oracle GoldenGate “hub” would need to support a heterogenous environment.  In these cases, a “hub” would look similar to the description above but with more software.  An example of a heterogenous “hub” would consist of (Oracle-to-Big Data):

  • Oracle GoldenGate Home (OGG_HOME (Microservices))
  • Oracle GoldenGate Deployment Home (OGG_DEPLOYMENT_HOME)
  • Nginx Reverse Proxy
  • Oracle Database Instant Client for Oracle 19c (ORACLE_HOME)
  • Oracle GoldenGate Home for Big Data (OGG_HOME (Classic))
  • Associated Client software for Big Data Platform (e.g. ElasticSearch REST API Client)

The image below illustrates how this would look for a single heterogenous “hub” of Oracle GoldenGate:



From the above image, you’ll notice that the “hub” has a large amount of Oracle GoldenGate Homes and Oracle Database Client homes.  This is due to the requirement that Oracle GoldenGate and Oracle Client software has to be installed three different times for each of the databases supported (11g, 12c, and 19c).  This leads to a bit of a bloated architecture within the “hub” approach.  This will become simpler in the near future when Oracle releases Oracle GoldenGate 21c for on-premises.  This is due to a new feature called “Unified Builds”.

“Unified Builds” – Single self-contained deployment which bundles database client libraries and supports Oracle databases per the published certified matrix.

Trail files

The next thing to understand about using Oracle GoldenGate in a “hub” configuration is what happens with the trail files.  In a typical Oracle GoldenGate architecture, the trail files would be shipped between locations (site-to-site).  Within an Oracle GoldenGate “hub”, trails files will be in one of two locations:

  • In a local mount point
  • Shipped between OGG_HOMEs
Local Mount Points

Using a local mount point for trail files is the simplest approach.  This is simply allocating a shared disk or NFS mount point where you want the trail files to be located.  From this location the extracts will create the trail files and the replicate will read the trail file.  There would be no shipping involved.  However, each of the Oracle GoldenGate homes/deployments (extract/replicats) would need access to the shared disk or NFS mount point.  Also depending on your log retention policy, the trail files could consume a signficate amount of space.

Shipping between OGG_HOMEs

This is one thing that confuses most people when they begin to look at Oracle GoldenGate “Hub” approaches.  How do the trail files get shipped between OGG_HOMEs?  The answer is simple – the same way they would be if not on the same box.  What is meant by that is, the Distribution Service will establish a path between the OGG_HOME/Deployments and ensure that the trail file is delivered as expected.


In this blog post, we tried to illustrate what an Oracle GoldenGate “Hub” would look like and how they are the backbone to the “data mesh” concept.  At the same time, provided two high-level views of what to expect on a “hub”.  The addressed the location on where the trail files should be placed and used from on the “hub”.  This was not meant to be an all encompassing solution, but a general approach to the Oracle GoldenGate “Hub” architecture.



About RheoData:

RheoData is a leader in Cloud and Hybrid architecture design, implementation, tuning, management and
monitoring.  We are your one-stop partner for on-premises, cloud, or hybrid environments.