======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:


<sxh bash>
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;
</sxh>


Wait it to sync again and check:

<sxh bash>
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> 
</sxh>