Enabling Bi-Directional Loop Detection

Loop detection is a requirement for bi-directional and multi-directional implementations of Oracle GoldenGate, so that an Extract for one source database does not recapture transactions sent by a Replicat from another source database.

With the CDC Extract capture method, by default, any transaction committed by a Replicat into a database where an Extract is configured, will recapture that transaction from the Replicat as long as supplemental logging is enabled for those tables that the Replicat is delivering to.

In order to ignore recapturing transactions that are applied by a Replicat, you must use the TRANLOGOPTIONS FILTERTABLE parameter for the CDC Extract. The table used as the filtering table will be the Oracle GoldenGate checkpoint table that you must create for the Replicat.

To create a Filter Table and enable Supplemental Logging:

  1. On each source database, ensure that a checkpoint table for use by Replicats has been created. For example:
    ADD CHECKPOINTTABLE ggadmin.oggcheck

    It is recommended that you use the same schema name as used in the GGSCHEMA parameter of the GLOBALS file.

  2. Enable supplemental logging for the checkpoint table. For example:
    ADD TRANDATA ggadmin.oggcheck ALLCOLS

  3. Ensure that the Replicat is created with the checkpoint table information.
    ADD REPLICAT reptgt1, EXTTRAIL ./dirdat/e2, CHECKPOINTTABLE ggadmin.oggcheck
  4. Configure each Extract with the IGNOREREPLICATES (on by default) and FILTERTABLE parameters, using the Replicat’s checkpoint table for the filtering table.
    TRANLOGOPTIONS IGNOREREPLICATES
    TRANLOGOPTIONS FILTERTABLE ggadmin.oggcheck

    Note:

    Oracle GoldenGate for PostgreSQL supports only one FILTERTABLE statement per Extract, so for multi-directional implementations, ensure each Replicat uses the same checkpoint table in the database that they deliver to.