A long time ago, OGG only supported deployment on the database host, which is called localized deployment. Now OGG supports remote deployment, that is, the OGG software is not installed on the database host, but on a separate machine, responsible for data extraction and delivery.
The benefits of this:
Easy to manage-When you run Oracle GoldenGate on a separate server, you can better manage OGG and reduce the impact on the production database. For example, hardware upgrades, performance adjustments, software repairs and upgrades, and other operations become easier to manage and risk more low. On the other hand, in the long run, you need centralized management to supervise all replication operations, mixing Oracle GoldenGate installations with database servers, making it difficult to implement such solutions. One of the reasons is that some database servers require very limited access! Third, you have more control to implement replication strategies, such as failover and replication load balancing.
Improved security-By moving data replication out of the database machine, usually in different security areas in the cloud, configuring different software components helps protect the database server.
Better performance-you don't want the replication process to affect the production database. When running GoldenGate on the database server, Oracle GoldenGate and the database share CPU, memory and disk IO resources. Therefore, it may happen that the copy process slows down database operations.
Technically feasible-Another important reason is that Oracle GoldenGate now widely supports remote capture and delivery, especially for Oracle databases. New features such as integrated capture and delivery improve the performance of remote capture and delivery, thereby helping you choose a new architecture with less impact on throughput.
Cloud needs-Many cloud hosted databases (such as Amazon AWS RDS databases) do not allow you to install anything on the database server. You have no choice but to run remote capture and delivery.
However, in some cases, local deployment may still be required:
Performance-The amount of data exceeds the network bandwidth that Oracle GoldenGate and the database server can handle, and throughput and latency cannot be processed by remote capture and transmission. Generally speaking, remote capture and delivery will bring about 15-20% performance loss. But this is not an official number, you need to decide the deployment plan after testing in your environment when evaluating the solution.
Switchover after Active Data Guard failure-To enable Oracle GoldenGate to support Active Data Guard failover, that is, when the priimary switches to standby, OGG extraction can be automatically connected, you need to deploy OGG to dbfs, for details, please refer to: http ://www.oracle.com/technetwork/database/availability/ogg-adg-2422372.pdf, in this case, OGG cannot be deployed remotely.
Operating System Endianness-The server running Oracle GoldenGate and the server running the database or database server must have the same Endianness. When the remotely deployed machine cannot provide the same byte order of the database server, it can only be deployed locally.
l OGG does not currently support-For some databases (such as MySQL, DB2 for i and DB2 for z/OS), Oracle GoldenGate does not support remote capture or delivery.
Support situation of OGG remote deployment
The support of the following DBs starts from 12.1.2.+
Oracle GoldenGate for Oracle DB (capture/delivery)
Oracle GoldenGate for MySQL (delivery)
Oracle GoldenGate for DB2 LUW (capture/delivery)
Oracle GoldenGate for Informix (capture/delivery)
Oracle GoldenGate for Big Data (delivery)
Oracle GoldenGate for Teradata (delivery)
Oracle GoldenGate for iSeries (delivery)
Oracle GoldenGate for SQL Server (delivery)
Oracle GoldenGate for JMS (capture/delivery)
For DB2 z/OS, Non-Stop, and SQL Server, Oracle GoldenGate does not currently support remote capture.
For DB2 iSeries, Oracle GoldenGate can capture from remote logs
For DB2 iSeries, Oracle GoldenGate supports remote log reading. This feature allows the GoldenGate capture program running on the remote IBM i system to read the log data generated from the main IBM i system.
This can eliminate the interaction between the Oracle GoldenGate extraction process and the main system, but Oracle GoldenGate still requires connection to the DB2 iSeries main system to read metadata information such as dictionary tables.
How to use remote capture and delivery
To run remote capture/posting, different databases use different methods.
Oracle GoldenGate for Oracle DB
You can perform remote capture using the following two methods:
(1) Use SQL*Net connection for integrated capture
(2) Real-time or archive log mode capture based on downstream. For the downstream data capture mode, you need to install Oracle Data Guard to continuously transfer the redo log files as "redo standby log" to the downstream database. The source database is required to be 10.2.0.4+, and the downstream database is 11.2.0.3.0+.
Oracle GoldenGate for DB2 LUW
Using DB2 connect, users can set remote DB2 as a local database instance. Then, Oracle GoldenGate can capture from a remote DB2 database through the local access point of DB2 connect.
Oracle GoldenGate for Informix
You can set up an ODBC connection to access the informix database on the remote server, and then Oracle GoldenGate can access the remote informix through ODBC. The following requirements need to be met: the endian of the two systems should be the same, the second is that the operating system platform and the number of bits (32-bit or 64-bit) must be the same. For example, from Linux to Linux, Windows to Windows, Solaris to Solaris, it cannot be cross-platform.
Oracle GoldenGate for MySQL
For MySQL, now Oracle GoldenGate only supports remote delivery, you only need to use TARGETDB, user name and password to specify the target database connection to start delivery. At the same time, the MySQL user is also required to have remote access permissions.
oracle goldengate remote capture and delivery