Overview
This is issue is caused by either of the following reasons:
- The source table has a column that does not exist in the target table, or it has a column that was excluded from replication (with a COLSEXCEPT clause). In either case, if that source column is updated, there will be no target column name to use in the SET clause within the Replicat SQL statement.
- An update is made that sets a column to the same value as the current one. The database does not log the new value, because it did not change. However, Oracle GoldenGate captures the operation as a change record because the primary key was logged, but there is no column value for the SET clause in the Replicat SQL statement.
In order to fix this, edit the param file for this replication as follows:
GGSCI (dst_server) 6> view params EBKREP1 Replicat Ebkrep1 USERID ggate, PASSWORD "password" --DBOPTIONS IntegratedPARAMS(parallelism 2) AssumeTargetDefs OVERRIDEDUPS --DiscardFile ./dirrpt/rpdw.dsc Map SCEMANAME1.*, target SCEMANAME1.*; Map SCEMANAME2.*, target SCEMANAME2.*; MapExclude IZOLAPROP.IB_SESSION; GGSCI (dst_server) 7> edit params EBKREP1 --change GGSCI (dst_server) 42> view params EBKREP1 Replicat Ebkrep1 USERID ggate, PASSWORD "password" --DBOPTIONS IntegratedPARAMS(parallelism 2) AssumeTargetDefs OVERRIDEDUPS ALLOWNOOPUPDATES <- Add this parameter --DiscardFile ./dirrpt/rpdw.dsc Map SCEMANAME1.*, target SCEMANAME1.*; Map SCEMANAME2.*, target SCEMANAME2.*; MapExclude IZOLAPROP.IB_SESSION;
Wait it to sync again and check:
GGSCI (dst_server) 43> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING REPLICAT RUNNING EBKREP1 00:00:00 00:00:05 REPLICAT RUNNING REP2 00:00:00 00:00:05 GGSCI (dst_server) 44>