As a quick review, the GoldenGate Hub Architecture is an architecture where GoldenGate extracts and replicats run; extracting from and replicating to other servers. The processing of GoldenGate is offloaded from the database servers. Only the 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.
Previous: Using the GoldenGate Hub Architecture