Sequence Error During Golden Gate Replication! Need Hints

Question

Dear All,
I am replicating 2 databases one way, from production to standby using golden gate.
Both databases are 11gR2 and on Linux.
Replication runs smooth for couple of days and then ends up with this error:
ERROR OGG-01296 Error mapping from ETISLBILLING.PAR_TBLPARNODEIDENTI to ETISLBILLING.PAR_TBLPARNODEIDENTI.
Parent Ket Not Found ETISLBILLING.FK_PARTNERNODE_IDENT
Trigger : ETISLBILLING.TRG_PAR_TBLPARTNERNODE Sequence : SEQ_PAR_TblPartnerIdenti
ORA-20000: Sequence value cannot be changed.
Main error is that value of sequence that is executed during the after insert trigger, does not change and trigger raise error hence the replication process is stopped.
I am just worried that the same triggers and sequences are executed successfully on production database and standby database has is exactly the same as production.
Is there some special treatment for sequences?
Kindly share your experience and give tips to handle this situation
Regards, Imran

Answer 1

Hi,
Hope this helps
Jan S.
FROM MOS: OGG Replicat Encounters OGG-01396 OGG-00869 ORA-01400 on Primary Key Column [ID 1308824.1]
Cause
==================
from the replicat report, first this error occurs:
WARNING OGG-01396 A complete after image is not available
in <schema.table> at rba 123456 in file ./dirdat/yyy, while inserting
a row into <schema.table> due to missing target row for a key update operation.
NOCOMPRESSUPDATES or FETCHOPTIONS FETCHPKUPDATECOLS may be specified in the
EXTRACT parameter file to include a complete image for key update operations.
The offending record is a primary key update, ... probably the key
<to be found at the mentioned rba 123456 in file ./dirdat/yyy> is not available on target
if the PK is not available at target side, then this error is expected, because HANDLECOLLISIONS turns the PK update into an insert as result of no target record to update.
The problem is that the source PK update record doesn't contain all the after image columns. That is also expected because the update record is intended to only update the affected columns.
As a workaround use FETCHOPTIONS FETCHPKUPDATECOLS on the capture/extract side to get all the after images of the record so that when a HANDLECOLLISIONS logic kicks in, it will be
able to successfully convert the original PK update into insert with all the after image present.
Solution
==================
First check the affected trail file yyy at RBA 123456 with logdump to verify, if the PK update does not have the complete key information as described.
If that is the case and the target table does not have the corresponding PK entry, this issue is hit. Otherwise it is something different.
As a workaround use
==================
FETCHOPTIONS FETCHPKUPDATECOLS on the capture/extract side to get all the after images of
the record so that when a HANDLECOLLISIONS logic kicks in, it will be
able to successfully convert the original PK update into insert with all the after image present.