Oracle Goldengate provides four different types of Replicats:

  • Classic Replicat
  • Coordinated Replicat
  • Integrated Replicat
  • Parallel Replicat
    • integrated mode
    • non-integrated mode

All types of Replicat are supported, and there are no plans to limit the kinds of Replicat. Each Replicats has its strength and set of use cases where it suits the best. For high-throughput environments Oracle recommends using Parallel Replicat.

Classic Replicat

Classic Replicat is the 1st Replicat from day One of GoldenGate. In low throughput environments, where classic Replicat can manage the about of database changes easily, this classic Replicat is adequate. The benefit of classic Replicat is that resource utilization is low. A common use case for classic Replicat is a target database fed by multiple source databases. If 50-100 sources route trail files to the target system, there can be 50-100 Replicat groups.

Coordinated Replicat
Coordinated Replicat has been available since Goldengate version 12.1, and it’s used to partition the workload into multiple threads. Earlier, customers might have 20 or 50 Replicat groups managing the workload from one source database. Say there are 100 independent schemas to replicate. This became difficult to manage. With coordinated Replicat, you can manage the full workload within one single process. Moreover, coordinated Replicat is also able to manage barrier events. These are DDL, Primary key Update (when using RANGE partition), Event Actions, and SQLEXEC. In the case of Barrier events, all threads finish their work before the barrier transaction is applied serialized. Then, the processing within multiple threads processes again.

Integrated Replicat
Integrated Replicat is also available since GoldenGate version 12.1. It is known for Oracle Databases only. Within integrated Replicat is a ‘client’ GoldenGate Replicat component and a ‘server’ component: the Inbound Server within the database. The sophisticated Apply engine uses multiple subprocesses within the database: A single Apply Network Receiver receives the changes, and a single Apply Reader computes dependencies between logical change records (LCRs) and assembles messages into transactions. The Apply Reader then returns the assembled transactions to the coordinator process. The coordinator process that gets transactions from the reader server schedules and passes them to apply servers. One or more Apply Servers processes (aka Appliers) that apply LCRs of a transaction to the database.

 

Most interesting is that Integrated Replicat not only manages Barrier Transactions (which are executed directly by Replicat). In addition to this, Integrated Replicat also runs a dependency calculation: If there are dependencies between the transactions, the Appliers will wait on each other (more Information about Dependency Calculation can be found in the previous blog post). For high-volume throughput environments where a single classic Replicat cannot keep up with the workload, a single integrated Replicat is a good choice because of the Dependency Calculation: Multiple classic Replicat groups would independently apply changes without any knowledge of dependencies. This is a great advantage of integrated Replicat. Beside this, there are also more functional options within integrated Replicat!

Parallel Replicat

Parallel Replicat is available since GoldenGate version 12.3 for Oracle Databases. It became available for non-Oracle Databases in GoldenGate version 21. Conceptually, the Parallel Replicat is very similar to the integrated Replicat. The critical difference is that the entire logic of Parallel Replicat is outside of the database.
As a result, Parallel Replicat can be used for non-Oracle databases such as DB2, SQL-Server, MySQL, and others. Parallel Replicat is an enhancement of the integrated Replicat. While Integrated Replicat only has a single Apply Receiver and Apply Reader process, the integrated Replicat has multiple ‘Input Streams’ to the main process, which is multithreaded and divided into a merger and scheduler sub-thread. Of course, the ‘Output Stream’ is managed by the parallelism of the Appliers that process transactions to the target database. Barriers and transaction dependency calculation are addressed by the main Replicat process outside of the database. Parallel Replicat also allows splitting large transactions into multiple pieces and applying those while maintaining transaction integrity (More information about this is available in the earlier blog).

In addition, the architectural evolution of Parallel Replicat, and the management and monitoring capabilities of Parallel Replicat have also been enhanced. Information about the table shapes and the capability of parallelism are available, GoldenGate statistics show the efficiency of parallelism, and even runtime dependency graphs are available.
Parallel Replicat is available in two modes:

  • Parallel Replicat in integrated mode (for Oracle databases)
    Note that Parallel Replicat in integrated mode is different than Integrated Replicat!
    As an example: Parallel Replicat in integrated mode is supported in Autonomous Database Serverless (ADB-S) while Integrated Replicat is not.
  • Parallel Replicat in non-integrated mode (for Oracle and non-Oracle databases)

Integrated Parallel Replicat in integrated mode contains more functionality, such as using:

  • Apply DML Handlers
  • Automatic Conflict Detection Resolution (ACDR)
  • Procedural Replication

Also, Parallel Replicat in integrated mode is using a Streaming Network Protocol.
The network discussion comes more into play if you decide to have a mid-tier (Hub) deployment where your GoldenGate instance is on a different server than the database server and you use the Database Net Service for the Remote Replicat.

If there are functional requirements for those features, you might want to use the Parallel Replicat in integrated mode. Regarding Performance, the Parallel Replicat in non-integrated mode is better in general. However, in a mid-tier (Hub) deployment where the network latency is much higher than 4-5 ms, you might want to use Parallel Replicat in integrated mode.

As described consistently in this current article, Each type of Replicat has its benefits and is best suited for specific use cases. If you have a low throughput environment where a classic Replicat is sufficient to manage the source database workload, you might want to stick with it. If the workload is much higher, you need parallelism- here, Parallel Replicat is the best choice.