1. It's a Design Decision
To many long time data replication experts, installing Oracle GoldenGate directly on database servers has been very successful. We call this approach the Native Capture and Delivery. Because the native capture and delivery works well, the question then becomes "Why do I need to make a change?" There are several reasons for you to consider the change:
- Easy Management - When running Oracle GoldenGate on a separate server, you can easily manage it with fewer impacts to your production database, and the operations like compute resource scaling, performance tuning, software patching and upgrade, become more manageable and with lower risk. On the other hand, in the long run, you need a centralized management to oversee all your replications, mixing Oracle GoldenGate installation with your database server, make it difficult to implement such solution. One of the reason is that some database server requires highly restricted access! Thirdly, you have more control to implement the replication policy such as fail-overs and replication load balancing.
- Improved Security - By moving data replication off the database machine and usually in the different security zone in the cloud helps protect the database server.
- Better Performance - You don't want the replication process to impact the production database. When running GoldenGate on the database server, the CPU, the memory, and the disk I/O resources are shared by Oracle GoldenGate and the database. Therefore, there could be situations when replication process slows down the database operation.
- Technical Readiness - Another important reason is that Oracle GoldenGate now extensively support remote capture and delivery, especially for Oracle Database. The new support such as integrated capture and delivery optimize the remote capture delivery performance and thus helps you choose the new architecture with fewer impacts on the throughput.
- Cloud Required - Many cloud-hosted databases, such as Amazon AWS RDS database, don't allow you to install anything on the database server. You have no choice but to run the remote capture and delivery.
2. When You Can't Use It
When thinking the remote capture and delivery is a good choice, there are limitations which prevent you from using it: Let me make it clear when you can't use remote capture and delivery.
- Performance - The the data volume exceed the network bandwidth between Oracle GoldenGate and Database Server can handle or throughput and lag time can't be handled by the remote capture and delivery. Remote capture and delivery, in general, gives you 15-20% downgrade of the native implementation. Note that this is an unofficial number, you need to test in your environment when evaluating the solution.
- Failing Over with Oracle Data Guard - To enabling Oracle GoldenGate to fail-over with Active Data Guard, you have to install Oracle GoldenGate on the database server and within the DBFS files system [1].
- OS Endianness - The server running Oracle GoldenGate and the server running the database or database server have to have the same Endianness. Please refer to Endianness and the Operating System [2] for more information.
- No Support - For some databases such as MySQL, DB2 for i and DB2 for z/OS, Oracle GoldenGate doesn't support remote capture and delivery. Please refer to Oracle GoldenGate Remote Capture and Delivery Support Overview [3] for more information.
Resources
- Oracle Technical Whitepaper, Transparent Role Transitions With Oracle Data Guard and Oracle GoldenGate, February 2015
- Jinyu's Blog - Endianness and the Operating System
- Jinyu's Blog - Oracle GoldenGate Remote Capture and Delivery Support Overview