Skip to main content

Command Palette

Search for a command to run...

[OGG] Replicat is running too slowly

Updated
4 min read
[OGG] Replicat is running too slowly
D

Ingeniero informático, Oracle ACE, DBA y Arquitecto OCI, con más de 15 años de experiencia en plataformas Oracle. Certificado en OCI Certified Architect Professional y OCI Migration and Integration Certified Professional.

If you prefer to read in Spanish Spanish version.

Today, let’s look at a case where the Replicat process is running too slowly.

The situation with OGG when they notified me was as follows:

GGSCI 1> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     EXXX        00:00:06      00:00:09
REPLICAT    RUNNING     Rxxx        53:14:49      00:00:03

The Replicat process RXXX had a lag from the beginning that kept growing and never decreased, how come?

As a small note, OGG is running on version 19.1.0.0.4.

First, let’s check the processing statistics in minutes:

GGSCI 4> stats replicat Rxxx, totalsonly *.*, reportrate min

Sending STATS request to REPLICAT Rxxx...

Start of Statistics at 2025-09-28 00:23:05.

DDL replication statistics:

*** Total statistics since replicat started     ***
        Opees rations                                       104.00
        Mapped operations                                  0.00
        Unmapped operations                              104.00
        Other operations                                   0.00
        Excluded operations                                0.00
        Errors                                             0.00
        Retried errors                                     0.00
        Discarded errors                                   0.00
        Ignored errors                                     0.00

Cumulative totals for specified table(s):

*** Total statistics since 2025-09-27 23:19:02 ***
        Total inserts/minute                       0.00
        Total updates/minute                       0.00
        Total deletes/minute                       0.00
        Total upserts/minute                       0.00
        Total discards/minute                  13497.48
        Total operations/minute                    0.00

*** Daily statistics since 2025-09-28 00:00:00 ***

        No database operations have been performed.

*** Hourly statistics since 2025-09-28 00:00:00 ***

        No database operations have been performed.

*** Latest statistics since 2025-09-27 23:19:02 ***
        Total inserts/minute                       0.00
        Total updates/minute                       0.00
        Total deletes/minute                       0.00
        Total upserts/minute                       0.00
        Total discards/minute                 864456.00
        Total operations/minute                    0.00

End of Statistics.

Here, we can observe performance issues, such as a lower number of operations compared to other processes, or very few DML operations.

Let’s review the process definition:

REPLICAT Rxxx

useridalias ogg_xxxx
assumetargetdefs

DDL INCLUDE ALL
DDLERROR DEFAULT IGNORE

discardfile ./dirrpt/Rxxx.dsc, Append,megabytes 4000
REPERROR (0001,discard)
REPERROR (1403,discard)

TABLE SCHEMA.TABLE , TARGET PDB.SCHEMA.TABLE;

Here, we can see several points. On one hand, the source is a single instance, while the target is multitenant. On the other hand, I didn’t see the HANDLECOLLISIONS parameter in the definition.

The HANDLECOLLISIONS parameter, it’s very useful in order to iron out the conflicts when the replicat is running. These conflicts are known as collisions.

This parameter helps OGG manage collisions efficiently, such as:

  • Insert: OGG tries to insert a row when that already exists in the target.

  • Update: OGG tries to perform an update when the row doesn’t exists in the target.

  • Delete: OGG tries to remove a row when the row doesn’t exists in the target.

Alright, enough talking theory! Let’s get our hands dirty!

We modified the process in order to include the parameter. You can see it below:

REPLICAT Rxxx

useridalias ogg_xxxx
assumetargetdefs

DDL INCLUDE ALL
DDLERROR DEFAULT IGNORE
HANDLECOLLISIONS

discardfile ./dirrpt/Rxxx.dsc, Append,megabytes 4000
REPERROR (0001,discard)
REPERROR (1403,discard)

TABLE SCHEMA.TABLE , TARGET PDB.SCHEMA.TABLE;

After running the process again, I waited a few hours in order to observe the results.

As you can see below, the process is working better than before.

GGSCI 1> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     EXXX        00:00:02      00:00:07
REPLICAT    RUNNING     Rxxx        26:38:41      00:00:00

Let’s check the processing statistics again:

GGSCI 3>   stats replicat Rxxx, totalsonly *.*, reportrate min

Sending STATS request to REPLICAT Rxxx...

Start of Statistics at 2025-09-28 12:19:43.

DDL replication statistics:

*** Total statistics since replicat started     ***
        Operations                                      4804.00
        Mapped operations                                  5.00
        Unmapped operations                             4799.00
        Other operations                                   0.00
        Excluded operations                                0.00
        Errors                                             7.00
        Retried errors                                     0.00
        Discarded errors                                   0.00
        Ignored errors                                     6.00

Cumulative totals for specified table(s):

*** Total statistics since 2025-09-28 00:26:27 ***
        Total inserts/minute                   63670.08
        Total updates/minute                       0.00
        Total deletes/minute                   54358.40
        Total upserts/minute                       0.00
        Total discards/minute                      0.00
        Total operations/minute               118028.47
        Total insert collisions/minute         63670.08
        Total delete collisions/minute         31318.92

*** Daily statistics since 2025-09-28 00:26:27 ***
        Total inserts/minute                   63670.08
        Total updates/minute                       0.00
        Total deletes/minute                   54358.40
        Total upserts/minute                       0.00
        Total discards/minute                      0.00
        Total operations/minute               118028.47
        Total insert collisions/minute         63670.08
        Total delete collisions/minute         31318.92

*** Hourly statistics since 2025-09-28 12:00:00 ***
        Total inserts/minute                    7272.71
        Total updates/minute                       0.00
        Total deletes/minute                  421092.52
        Total upserts/minute                       0.00
        Total discards/minute                      0.00
        Total operations/minute               428365.24
        Total insert collisions/minute          7272.71
        Total delete collisions/minute        421092.52

*** Latest statistics since 2025-09-28 00:26:27 ***
        Total inserts/minute                45413289.00
        Total updates/minute                       0.00
        Total deletes/minute                38771646.00
        Total upserts/minute                       0.00
        Total discards/minute                      0.00
        Total operations/minute             84184935.00
        Total insert collisions/minute      45413289.00
        Total delete collisions/minute      22338520.00

End of Statistics.

Here, we can observe several points:

  • The number of operations has exceeded 4000 instead of 104.

  • The dml workflow is working properly.

The performance issue has been worked out.

Caso Cerrado Telemundo GIF by Universo (imagen GIF)

I hope you enjoyed reading this post :)