The GoldenGate Hub Architecture is an implementation of GoldenGate that removes the extracts and replicats from a traditional deployment of running on the same server as the database, to running them on a separate server.
The processing of GoldenGate replications is offloaded from the database servers.
Only the internal database portion of GoldenGate processing is running on the database servers.
Those of you who have been using GoldenGate for a long time might be skeptical of the performance of this model, since the processing is now not being done close to the server.
Well, there is some network processing that is involved but it is overshadowed by the benefit you gain from offloading GoldenGate processing.
Let’s look at how the GoldenGate extract works. The extract mines the Oracle redo log, maintaining transactions in memory. When the commit record is reached the extract pulls together (from its memory) all the operations involved in the transaction and writes them to the trail file. Much of the processing involves maintaining the transactions in memory and writing out the trail file. By offloading this processing, you not only save a lot of memory on the database server, but significant processing as well.
In fact, keep in mind that by default, the maximum amount of memory an extract can use is 64GB. This can be significant and cause problems on a database server. Thus, there are several benefits to offloading the GoldenGate extract from the database server an on to the GoldenGate Hub.
This method of configuring GoldenGate is proven to deliver high performance and to offload much of the overhead from the database server. I would recommend this method.