When goldengate process is unable to process transaction it generates a discard and makes process abended. When ever a discard is generated, i.e out of sync situation in the environment. we need to update the records manually on target tables. If the goldengate process is discarding records into the discard file in a huge manner, there are different things where Goldengate admin should look into. we have to validate things at goldengate level for example: supplemental logging and make sure all database components ex: trigger, constraints are valid on database
example of discard file:
Here data is not found - ORA-01403, indicates when ever replicat is trying to update a record in target table that don't exists. We need to find out that really this records exists in target database.
OCI Error ORA-01403: no data found, SQL <UPDATE "UNIVERSE"."WORLD" SET "ID" = :a0,"DSL" = :a4,"MASK" = :a5 WHERE "SD" = :b0 AND "CLL" = :b1 AND "LID" = :b2>
Operation failed at seqno 3341 rba 215631485
Discarding record on action DISCARD on error 1403
Problem replicating UNIVERSE.WORLD to UNIVERSE.WORLD
Record not found
Mapping problem with compressed update record (target format)...
*
ID = BUJKILJI
SD = N
CLL = XHIML
LID = LOPLSLS
DSL = Y
MASK = OPOPOPOPDPXDDD
-----Nikhil Tatineni
-----Oracle in memory
example of discard file:
Here data is not found - ORA-01403, indicates when ever replicat is trying to update a record in target table that don't exists. We need to find out that really this records exists in target database.
OCI Error ORA-01403: no data found, SQL <UPDATE "UNIVERSE"."WORLD" SET "ID" = :a0,"DSL" = :a4,"MASK" = :a5 WHERE "SD" = :b0 AND "CLL" = :b1 AND "LID" = :b2>
Operation failed at seqno 3341 rba 215631485
Discarding record on action DISCARD on error 1403
Problem replicating UNIVERSE.WORLD to UNIVERSE.WORLD
Record not found
Mapping problem with compressed update record (target format)...
*
ID = BUJKILJI
SD = N
CLL = XHIML
LID = LOPLSLS
DSL = Y
MASK = OPOPOPOPDPXDDD
Root cause:
STEP1: CHECK SUPPLEMENTAL LOGGING ON SOURCE TABLE
STEP2: CHECK DATA ON THE SOURCE TRAIL and make sure what are the columns getting logged into trail from online redo
STEP3: ANY KEYS COLS USED IN REPLICAT(KEYS COLS SHOULD NOT BE UPDATED on source )
STEP4: Check any null values are logged on the trail where replicat unable to make consistent sql to apply to target database
for example:
Mapping problem with compressed update record (target format)...
*
ID =
SD =
CLL =
LID = LOPLSLS
DSL = Y
MASK = OPOPOPOPDPXDDD
-----Nikhil Tatineni
-----Oracle in memory