Skip to main content

Oracle GoldenGate – Integrated Replicat

By October 5, 2018September 1st, 20193 Comments

Oracle GoldenGate – Integrated Replicat

Integrated Replicat was introduced from the Oracle GoldenGate 12c. Similar to Integrated Extract, Integrated Replicat is also tightly coupled with Oracle Database.

Integrated Replicat operates as below,

  • Reads the OGG Trail files which are pushed by the Data Pump process from the Source.

  • Performs filtering, mapping and conversion of data.

  • Constructs logical change records (LCRs) of the Source DML transactions in committed order. DDL operations are applied directly by Replicat.

  • Attaches the Database Inbound Server to the database by means of a Lightweight Streaming API.

  • Transfers the constructed LCRs to the Inbound Server which then applies the data to the Target Database.

Like Integrated Extract, you can also configure parallelism in Integrated Replicat process. Multiple Inbound Server child processes which are known as APPLY SERVERS applies data in parallel to the target database maintaining the original transaction atomicity. Below is the architecture diagram of the Integrated Replicat,

By default, Integrated Replicat applies the transactions Asynchronously. Transactions which are with no dependencies are applied safely executed and committed out of order to achieve fast throughput. Transactions which are dependencies are applied in the same order as on the source.

Integrated Replicat process also has it’s own sub processes which are as below,

    • REPLICAT – Reads the trail files and constructs the LCRs and then transfers it to the database using the LLghtweight Streaming API.

    • RECEIVER – Reads the LCRs

    • PREPARER – It computes the dependencies of the transactions and sort them in order.

    • COORDINATOR – Coordinates the transactions and maintains the order between the Applier processes.

    • APPLIER – Applies the transactions to the database. Also, performs the changes for the transactions received from coordinator including CDR and error handling.



If the Inbound Server does not support any column data types or any other feature, it automatically applies the transactions to the database in DIRECT APPLY (Classic mode) using the OCI.

The following features are applied in DIRECT MODE by the Integrated Replicat:

      • DDL operations

      • Sequence operations

      • SQLEXEC parameter within a TABLE or MAP parameter

      • EVENTACTIONS processing

      • UDT Note, if the extract uses USENATIVEOBJSUPPORT to capture the UDT, then integrated Replicat will apply it with the inbound server, otherwise it will be handled by Replicat directly.

For example, if you have more of DDL operations or Sequence operations, then the Integrated Replicat will switch to Direct Apply to apply these operations and then switch back to Integrated Mode. This degrades the performance of the Integrated Replicat process even though if you set sufficient parallelism and memory.

Below are the advantages of the Integrated Replicat over the Classic or Non-Integrated Replicat process.,

      • Integrated Replicat supports parallelism and hence it applies the transactions in parallel which gives good performance rate while preserving the integrity and atomicity of the source transaction.. The parallelism can be set using the parameter PARALLELISM and MAX_PARALLELISM. The parallel apply servers increases and decreases automatically according to the workload.

      • There is no need of Range Replicat processes if you have huge tables. Integrated Replicat is very easy to configure and only one IR is enough as it supports parallelism.

      • High-performance apply streaming is enabled for integrated Replicat by means of a lightweight application programming interface (API) between Replicat and the inbound server.

      • Integrated Replicat process coordinates and handles the barrier transactions among multiple server apply processes.

      • When a DDL operations is seen, Integrated Replicat processes it as direct transactions that force a barrier by waiting for server processing to complete before the DDL execution.

      • Integrated Replicat process easily handles the Transient duplicate primary key updates.

      • Integrated Replicat can be configured in a single or pluggable databases (Multitenant).

To configure Integrated Replicat process there are some requirements which are below,

      • The Target database should be Oracle and later.

      • Supplemental Logging should be enabled on the Source.

      • When using this Integrated Replicat, you need to enable trandata at OGG level using ADD SCHEMATRANDATA and not with ADD TRANDATA. Also, you need to use the parameter LOGALLSUPCOLS at the source Extract paraemeter file. Else, you will be hitting “ORA-26688: missing key in LCR”.

      • Integrated Replicat process can be used only in Oracle Database. It doesn’t supports Non-Oracle databases.

      • Need to set STREAMS_POOL_SIZE

This plays a vital role in the Integrated Feature. You need to configure explicitly the Streams_Pool_Size when you configure the Integrated Mode of Capture.
Integrated Capture takes or consumes memory from the STREAMS_POOL_SIZE. There are some calculations to size the streams pool. Please check the below link on
how to size this STREAMS_POOL

Memory requirement for Oracle GoldenGate Integrated Extract

      • Need to apply the RECOMMENDED PATCHES

There are some recommended patches to be applied to the Oracle Database when using the Integrated Capture/Replicat. Please check the below KM Note.,

Oracle GoldenGate — Oracle RDBMS Server Recommended Patches (Doc ID 1557031.1)

Latest GoldenGate/Database (OGG/RDBMS) Patch recommendations (Doc ID 2193391.1)

Let’s go in to the configuration now,

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 2> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt


Add the parameters for the Integrated Replicat process “INREP”

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 3> edit params INREP

USERID ggadmin, PASSWORD oracle
MAP source.t1, TARGET target.t1;

Save the file and check the parameters once.

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 4> view params INREP

USERID ggadmin, PASSWORD oracle
MAP source.t1, TARGET target.t1;

DBOPTIONS INTEGRATEDPARAMS(parallelism 6) – denotes that for this Integrated Replicat, you are specifying a minimum number of parallel apply processes which will be 6.

To know more about these options, please refer to the below link,

All the pre-requisites are taken care already. In my last post, we saw about the Integrated Extract process. We need to register the Integrated Extract process. But, Integrated Replicat process will be registered automatically to the database. So, we don’t want to explicitly register the Integrated Replicat process. So, let’s just add the Integrated Replicat process,

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 5> add replicat inrep INTEGRATED exttrail ./dirdat/lt
REPLICAT (Integrated) added.

You could see an Integrated Replicat process is created.

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 10> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

REPLICAT    STOPPED     INREP       00:00:00      00:01:38

Now Start the IR process,

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 14> start INREP

Sending START request to MANAGER ...

Now the process is in RUNNING state.

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 15> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING REPLICAT RUNNING INREP 00:00:00 00:02:20

Below are the Entries in the Alert log file,

GoldenGate APPLY AP02 for OGG$INREP started with pid=25, OS id=3023
APPLY OGG$INREP: Apply Tag: 00
APPLY OGG$INREP: Parameter Set by User: PARALLELISM Value: 6
APPLY OGG$INREP: Parameter Set by User: EAGER_SIZE Value: 15100
Sat Sep 29 11:42:29 2018
GoldenGate Apply Reader for OGG$INREP started AS01 with pid=27 OS id=3025
Sat Sep 29 11:42:29 2018
Sat Sep 29 11:42:29 2018
GoldenGate Apply Server for OGG$INREP started AS02 with pid=28 OS id=3027
Sat Sep 29 11:42:29 2018
GoldenGate Apply Server for OGG$INREP started AS04 with pid=30 OS id=3031
GoldenGate Apply Server for OGG$INREP started AS06 with pid=32 OS id=3035
Sat Sep 29 11:42:29 2018
Sat Sep 29 11:42:29 2018
GoldenGate Apply Server for OGG$INREP started AS03 with pid=29 OS id=3029
GoldenGate Apply Server for OGG$INREP started AS05 with pid=31 OS id=3033
Sat Sep 29 11:42:29 2018
GoldenGate Apply Server for OGG$INREP started AS07 with pid=33 OS id=3037
APPLY OGG$INREP: Source Database: NA
APPLY OGG$INREP: Applied Message Number: NA
APPLY OGG$INREP: Message Create Time: NA
Sat Sep 29 11:42:30 2018
Propagation Receiver (CCA) for GoldenGate replicat and Apply OGG$INREP with pid=34, OS id=3021, objnum=0 started.

Below is the information in the report file of the Integrated Replicat process,

                 Oracle GoldenGate Delivery for Oracle
    Version OGGCORE_12.
   Linux, x64, 64bit (optimized), Oracle 11g on Jul 21 2017 20:36:55

Copyright (C) 1995, 2017, Oracle and/or its affiliates. All rights reserved.

                    Starting at 2018-09-29 11:42:22

Operating System Version:
Version #1 SMP Wed Feb 2 18:40:23 EST 2011, Release 2.6.32-100.28.5.el6.x86_64
Node: OGGR2-1.localdomain
Machine: x86_64
                         soft limit   hard limit
Address Space Size   :    unlimited    unlimited
Heap Size            :    unlimited    unlimited
File Size            :    unlimited    unlimited
CPU Time             :    unlimited    unlimited

Process id: 3016


2018-09-29 11:42:22  WARNING OGG-02904  Replication of PARTIAL XML containing NCHAR/NVARCHAR/NCLOB data may cause divergence.

**            Running with the following parameters                  **

2018-09-29 11:42:22  INFO    OGG-03059  Operating system character set identified as UTF-8.

2018-09-29 11:42:22  INFO    OGG-02695  ANSI SQL parameter syntax is used for parameter parsing.

2018-09-29 11:42:22  INFO    OGG-01360  REPLICAT is running in Integrated mode.
USERID ggadmin, PASSWORD ***
MAP source.t1, TARGET target.t1;

2018-09-29 11:42:23  INFO    OGG-06451  Triggers will be suppressed by default.

2018-09-29 11:42:23  INFO    OGG-01815  Virtual Memory Facilities for: COM
    anon alloc: mmap(MAP_ANON)  anon free: munmap
    file alloc: mmap(MAP_SHARED)  file free: munmap
    target directories:

Database Version:
Oracle Database 11g Enterprise Edition Release - 64bit Production
PL/SQL Release - Production
CORE      Production
TNS for Linux: Version - Production
NLSRTL Version - Production

Database Language and Character Set:

2018-09-29 11:42:23  INFO    OGG-06604  Database GGDB1 CPU info: CPU Count 1, CPU Core Count 0, CPU Socket Count 0.

2018-09-29 11:42:23  WARNING OGG-05673  CSN-based duplicate suppression is disabled because there is no checkpoint table for this Replicat.

2018-09-29 11:42:23  INFO    OGG-02545  Parameter GROUPTRANSOPS is ignored by Integrated Replicat when parallelism is greater than 1.

2018-09-29 11:42:23  INFO    OGG-02527  Integrated Replicat does not populate a trace table.

2018-09-29 11:42:30  INFO    OGG-02530  Integrated replicat successfully attached to inbound server OGG$INREP.

**                     Run Time Messages                             **

2018-09-29 11:42:30  INFO    OGG-02243  Opened trail file /ogg/dirdat/lt000000000 at 2018-09-29 11:42:30.874662.

2018-09-29 11:42:30  WARNING OGG-02760  ASSUMETARGETDEFS is ignored because trail file /ogg/dirdat/lt000000000 contains table definitions.

2018-09-29 11:42:30  INFO    OGG-03522  Setting session time zone to source database time zone 'GMT'.

2018-09-29 11:42:30  INFO    OGG-02232  Switching to next trail file /ogg/dirdat/lt000000001 at 2018-09-29 11:42:30.874662 due to EOF. with current RBA 1,401.

2018-09-29 11:42:30  INFO    OGG-03506  The source database character set, as determined from the trail file, is we8mswin1252.
Processed extract process graceful restart record at seq 1, rba 1401.

How to check if the replicat process created or running is a Classic or Integrated? It is simple. We can see the keyword INTEGRATED in the below command output,

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 16> info INREP

REPLICAT   INREP     Last Started 2018-09-29 11:42   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:09 ago)
Process ID           3016
Log Read Checkpoint  File /ogg/dirdat/lt000000001
                     2018-09-29 11:17:08.839373  RBA 1461

Below is the detailed information of the Integrated Replicat process,

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 17> info INREP, detail

REPLICAT   INREP     Last Started 2018-09-29 11:42   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:04 ago)
Process ID           3016
Log Read Checkpoint  File /ogg/dirdat/lt000000001
                     2018-09-29 11:17:08.839373  RBA 1461

DBLOGIN Provided, inbound server name is OGG$INREP in ATTACHED state

Current Log BSN value: (no data)

Low Watermark CSN value: (no data)

High Watermark CSN value: (no data)

  Extract Source                          Begin             End

  /ogg/dirdat/lt000000001                 * Initialized *   2018-09-29 11:17
  /ogg/dirdat/lt000000000                 * Initialized *   First Record
  ./dirdat/lt000000000                    * Initialized *   First Record

Current directory    /ogg

Report file          /ogg/dirrpt/INREP.rpt
Parameter file       /ogg/dirprm/inrep.prm
Checkpoint file      /ogg/dirchk/INREP.cpr
Process file         /ogg/dirpcs/INREP.pcr
Error log            /ogg/ggserr.log

One of the difference between Classic Replicat and Integrated Replicat is, like Classic Replicat process, Integrated Replicat does not have a Checkpoint Table. In the above output, you can clearly see there is no checkpoint table details. So, where does the Integrated Replicat stores it’s checkpoint information apart from the checkpoint file? Integrated Replicat is integrated with database, which means Oracle database knows about it. There are several Oracle GoldenGate views defined in the database data dictionary which can be queried to display information about Oracle GoldenGate queues and processes.

To check the Checkpoint information, below is the view.,

 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 SERVER_NAME                               NOT NULL VARCHAR2(30)
 PROCESSED_LOW_POSITION                             VARCHAR2(4000)
 APPLIED_LOW_POSITION                               VARCHAR2(4000)
 APPLIED_HIGH_POSITION                              VARCHAR2(4000)
 SPILL_POSITION                                     VARCHAR2(4000)
 OLDEST_POSITION                                    VARCHAR2(4000)
 APPLIED_LOW_SCN                           NOT NULL NUMBER
 APPLIED_TIME                                       DATE
 APPLIED_MESSAGE_CREATE_TIME                        DATE
 SOURCE_DATABASE                           NOT NULL VARCHAR2(128)
 LOGBSN                                             VARCHAR2(4000)

To know about the Integrated Applier details,

 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 REPLICAT_NAME                                      VARCHAR2(4000)
 SERVER_NAME                               NOT NULL VARCHAR2(30)
 APPLY_USER                                         VARCHAR2(30)
 USER_COMMENT                                       VARCHAR2(4000)
 CREATE_DATE                                        TIMESTAMP(6)
 STATUS                                             VARCHAR2(8)
SQL> select replicat_name,server_name from ggadmin.DBA_GOLDENGATE_INBOUND;

------------------------------ ------------------------------
INREP                          OGG$INREP
SQL> desc ggadmin.DBA_APPLY
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 APPLY_NAME                                NOT NULL VARCHAR2(30)
 QUEUE_NAME                                NOT NULL VARCHAR2(30)
 QUEUE_OWNER                               NOT NULL VARCHAR2(30)
 APPLY_CAPTURED                                     VARCHAR2(3)
 RULE_SET_NAME                                      VARCHAR2(30)
 RULE_SET_OWNER                                     VARCHAR2(30)
 APPLY_USER                                         VARCHAR2(30)
 APPLY_DATABASE_LINK                                VARCHAR2(128)
 APPLY_TAG                                          RAW(2000)
 DDL_HANDLER                                        VARCHAR2(98)
 PRECOMMIT_HANDLER                                  VARCHAR2(98)
 MESSAGE_HANDLER                                    VARCHAR2(98)
 STATUS                                             VARCHAR2(8)
 MAX_APPLIED_MESSAGE_NUMBER                         NUMBER
 NEGATIVE_RULE_SET_NAME                             VARCHAR2(30)
 NEGATIVE_RULE_SET_OWNER                            VARCHAR2(30)
 STATUS_CHANGE_TIME                                 DATE
 ERROR_NUMBER                                       NUMBER
 ERROR_MESSAGE                                      VARCHAR2(4000)
 MESSAGE_DELIVERY_MODE                              VARCHAR2(10)
 PURPOSE                                            VARCHAR2(19)
SQL> select apply_name,queue_name from ggadmin.DBA_APPLY;

APPLY_NAME                     QUEUE_NAME
------------------------------ ------------------------------
OGG$INEXT                      OGG$Q_INEXT
OGG$INREP                      OGGQ$INREP

Hope this post given you a clear view about the Integrated Replicat process. Will explain about the Coordinated Replicat in my next post.

Cheers 🙂


  • Shekar says:

    Can we know the exact rba replicate is reading from the trail file. Let me provide the scenario.

    I do Info replicat REP and it provides me log read checkpoint at file009. However I ran a delete statement on source side which deleted 3 million rows and they are split in 5 trail files from seq file009 to file014. It is one transaction. How do we know how many records Gg replicate process has read and applied.

    We are on GG 12.3 and have configured integrated parallel replicat with 6 processes for replicat.

    Thanks for ur time

    • You can use the SEND command to check the progress of the replicat process. INFO command will give you old detail. It fetches the information from checkpoint file and the checkpoint file will get updated by the process only when it sees a COMMIT. SEND command will directly communicate to the process and gives you the latest information.

  • mushraff says:

    your articles are really helpful. Thanks for sharing.

Leave a Reply

© 2020 ORACLE-SCN. All Rights Reserved.