Oracle GoldenGate – Replicat – Classic, Integrated and Coorindated

Nonintegrated or “Classic” Replicat

  • Trail files contain OGG canonical format
  • Data applied through “normal” SQL-type channels
  • Available for any supported platform, multiple vendors
  • Heterogeneous, that is, source and target could be in almost any database

The universal trail files are used to construct SQL DML and/or DDL statements customized to the target database vendor syntax. The SQL statements then apply the data. The target database often is not aware that the data is coming from Oracle GoldenGate; it appears to be regular plain old SQL commands as if a user typed them in.

  • DDL replication, if enabled, is supported on either an Oracle or Teradata (12.1.2) environment.
  • This mode is available on almost every database platform (including Oracle) and every version (with some rare exceptions). You can start with Classic (NonIntegrated) Replicat and then later convert it (using alter Replicat command) to Integrated if the platform permits it.

Syntactical Example as per Replicat Mode

Classic Replicat: add replicat rfina, extrail ./dirdat/es
Integrated Replicat: add replicat rfina, integrated exttrail ./dirdat/es
Coordinated Replicat: add replicat rfina, coordinated, exttrail ./dirdat/es
Parallel Replicat in Integrated Mode: add replicat rfina, integrated, parallel, exttrail ./dirdat/es checkpointtable ggadmin.ggs_checkpoint
Parallel Replicat in NonIntegrated Mode: add replicat rfina, parallel, exttrail ./dirdat/es checkpointtable ggadmin.ggs_checkpoint

  • Replicat process, by default checks for changing (Remote Trail Files) every second, and build SQL statement.
  • Each Replicat has its own parameter file.
  • Some Times, Replicat refer as Mapper.

Integrated Replicat (Integrated Delivery)

  • Trail files contain data in either canonical for LCR (Logical Change Record) format.
  • Data is applied through XStream In API, it is very efficient, and bypasses overhead.
  • Introduced in GoldenGate 12c. Available for only the latest Oracle Database platforms ( or higher).
  • Source can be anything, but target must be Oracle Database.
  • Source can be classic or integrated Extract.
  • Integrated Replicat does not need a checkpoint table or a trace table for its operations.

In Integrated Replicat, Inbound Server contains Receiver, Preparer, Coordinator and one or more Applier. The integrated Replicat applies transactions asynchronously, Transactions that do not have interdependencies can be safely executed and committed out of order to achieve fast throughput. Transactions with dependencies are guaranteed to be applied in the same order as on the source.

Logical Change Records (LCRs) are created by Integrated Extract, whereas canonical is created by Classic Extract. Integrated Replicat uses lightweight XStream In API from the Replicat process to an Inbound Server, and converts canonical to LCR format if needed:

  • Receiver: Reads trails in LCR format
  • Preparer (Reader): Computes the dependencies between the transactions (primary key, unique indexes, foreign key), grouping transactions and sorting in dependency order
  • Coordinator: Coordinates transactions; maintains the order between applier processes
  • Appliers: Performs changes for assigned transactions, including conflict detection and error handling

There are several database SYS dictionary tables and views named V$GG_APPLY_* and DBA_APPLY_*. Integrated Replicat is supported only on Oracle Database versions and later. Integrated Replicat does not support GGSCI parameter such as BULKLOAD, GENLOADFILES, RMTTASK, and SPECIALRUN; they cause an abort. There is limited functionality for SHOWSYNTAX, which does not abort but does not show interactive commands either.

Coordinated Replicat

  • Work with Oracle and Non-Oracle Database
  • Its multithreaded and can have multiple Replicat threads and typically each thread has its own Checkpoint File.
  • Uses one parameter file and typically one trail file, which all Replicat processes (threads) read.

Coordinated Replicat is also known as coordinated apply. This is independent of Integrated Replicat, and it works on most versions and most vendors’ databases. The main feature is that all of the Replicat threads can apply in parallel, though there may be cases where a full barrier synchronization (serialization) is desirable.

  • Coordinator: It is responsible for thread creation and shutdown, dependency coordination, and statistics aggregation.
  • Multiple checkpoints: If there are n threads, there are n+1 checkpoint files, one for each thread and a coordinator’s checkpoint file, plus the checkpoint table in the database.
  • Single Parameter file: The greatly simplifies configuration, maintenance, and use.
  • Single trail file: You do not need to figure out how to split up the work. The Replicat coordinator process does that.

By default, the Coordinated Replicat sets up a maximum of 25 threads (there are actually 26, including one coordinator thread plus 25 Replicat threads), but you can increase or decrease this maximum up to 500 threads.

  • Note:
    The group name of a coordinated Replicat can contain only five characters.
    Do not use initial load SpecialRun or ExtFile with Coordinated Replicat options.
Share This

Muhammad Rawish Siddiqui

Master in Computer Science (Database Engineering) and PGD in Management Information System.
45+ Online Certifications, which includes EDRP (EC-Council Disaster Recovery Professional), Data Management, Security+, DBaaS - Cloud Certified Expert, Oracle Cloud Autonomous Database Specialist, Oracle Database Cloud Certified Professional, Oracle Cloud Infrastructure, OCP 7.3, 10g, 11g, 11i, R12, OCE/OCS 11i System Administration, Solaris, Linux and Real Application Cluster 10g, 11g, Oracle Autonomous Database, Real Application Cluster, Oracle Data Guard and Performance Tuning etc. .

Foremost interested areas include, Data Management, Oracle Databases and EBS Health Checks, Real Application Cluster, Disaster Recovery, GoldenGate and Oracle Cloud.
Notify of
Inline Feedbacks
View all comments