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:
-
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 theGLOBALS
file. -
Enable supplemental logging for the checkpoint table. For example:
ADD TRANDATA ggadmin.oggcheck ALLCOLS
-
Ensure that the Replicat is created with the checkpoint table information.
ADD REPLICAT reptgt1, EXTTRAIL ./dirdat/e2, CHECKPOINTTABLE ggadmin.oggcheck
-
Configure each Extract with the
IGNOREREPLICATES
(on by default) andFILTERTABLE
parameters, using the Replicat’s checkpoint table for the filtering table.TRANLOGOPTIONS IGNOREREPLICATES TRANLOGOPTIONS FILTERTABLE ggadmin.oggcheck
Note:
Oracle GoldenGate for PostgreSQL supports only oneFILTERTABLE
statement per Extract, so for multi-directional implementations, ensure each Replicat uses the same checkpoint table in the database that they deliver to.