Preventing Data Looping
In a bidirectional configuration, SQL changes that are replicated from one system to another must be prevented from being replicated back to the first system. Otherwise, it moves back and forth in an endless loop, as in this example:
A user application updates a row on system A.
Extract extracts the row on system A and sends it to system B.
Replicat updates the row on system B.
Extract extracts the row on system B and sends it back to system A.
The row is applied on system A (for the second time).
This loop continues endlessly.
To prevent data loopback, you may need to provide instructions that:
prevent the capture of SQL operations that are generated by Replicat, but enable the capture of SQL operations that are generated by business applications if they contain objects that are specified in the Extract parameter file.
identify local Replicat transactions, in order for the Extract process to ignore them.
9.3.1 Preventing the Capture of Replicat Operations
Depending on which database you are using, you may or may not need to provide explicit instructions to prevent the capture of Replicat operations.
9.3.1.1 Preventing the Capture of Replicat Transactions (Oracle)
To prevent the capture of SQL that is applied by Replicat to an Oracle database, there are different options depending on the Extract capture mode:
When Extract is in classic or integrated capture mode, use the TRANLOGOPTIONS parameter with the EXCLUDETAG tag option. This parameter directs the Extract process to ignore transactions that are tagged with the specified redo tag. See Section 9.3.2 to set the tag value.
When Extract is in classic capture mode, use the Extract TRANLOGOPTIONS parameter with the EXCLUDEUSER or EXCLUDEUSERIDoption to exclude the user name or ID that is used by Replicat to apply transactions. Multiple EXCLUDEUSER statements can be used. The specified user is subject to the rules of the GETREPLICATES or IGNOREREPLICATES parameter. See Section 9.3.1.3 for more information.
9.3.1.2 Preventing Capture of Replicat Transactions (Teradata)
To prevent the capture of SQL that is applied by Replicat to a Teradata database, set the Replicat session to override Teradata replication. Use the following SQLEXEC statements at the root level of the Replicat parameter file:
SQLEXEC 'SET SESSION OVERRIDE REPLICATION ON;'SQLEXEC 'COMMIT;'
These SQLEXEC statements execute a procedure that sets the Replicat session automatically at startup.
9.3.1.3 Preventing Capture of Replicat Transactions (Other Databases)
To prevent the capture of SQL that is applied by Replicat to other database types (including Oracle, if Extract operates in classic capture mode), use the following parameters:
GETAPPLOPS | IGNOREAPPLOPS: Controls whether or not data operations (DML) produced by business applications except Replicatare included in the content that Extract writes to a specific trail or file.
GETREPLICATES | IGNOREREPLICATES: Controls whether or not DML operations produced by Replicat are included in the content that Extract writes to a specific trail or file.
FYI
https://docs.oracle.com/goldengate/1212/gg-winux/GWUAD/wu_bidirectional.htm#GWUAD302
