This discussion is archived
4 Replies Latest reply: Jan 13, 2013 11:49 PM by -joe RSS

Common GoldenGate errors

N.Page Newbie
Currently Being Moderated
GG version 11.2.1.0.3
OS: Unix/Unix-like

For a typical Unidirectional configuration where only DML is replicated , what are the most common errors you usually encounter with GoldenGate ? Just name a few.
  • 1. Re: Common GoldenGate errors
    N K Pro
    Currently Being Moderated
    There shouldn't be any if you configure it properly and perform a successful initial load.

    If you dont, many different things could happen the most common I can think of is your data being out of sync and getting several SQL 1403 errors which is "Row not found".

    Greetings,
    N K
  • 2. Re: Common GoldenGate errors
    N.Page Newbie
    Currently Being Moderated
    Thank you NK. This particular error 1203 means that an UPDATE or DELETE was performed at source and when the replicat tried to replicate that change in the target table, it couldn't find that row. Right ?
    Network outage or server outage could be one of the reason for the Target not to be in sync. But once the network/server issues are fixed the 'pending' changes will be applied . So, how could the target become out of sync ?
  • 3. Re: Common GoldenGate errors
    N K Pro
    Currently Being Moderated
    N.Page wrote:
    Thank you NK. This particular error 1203 means that an UPDATE or DELETE was performed at source and when the replicat tried to replicate that change in the target table, it couldn't find that row. Right ?
    Network outage or server outage could be one of the reason for the Target not to be in sync. But once the network/server issues are fixed the 'pending' changes will be applied . So, how could the target become out of sync ?
    1403*

    Right. Other errors you could face with data out of sync are constraints errors for DML operations.

    Network or server outage could break the communication but goldengate should resume from where it left off.
    There are not many ways of target becoming out of sync, and they are mostly through human intervention. e.g. dml applied to target and not comming from a transaction applied by goldengate, or your replicat abends on target for some reason and they decide to skip a transaction that they shouldnt have, that kind of thing.
    As I said, if the initial load is successfull you should be fine and no errors should arise if your configuration is correct.
    If you happen to configure 2 replicats due to high transactions make sure tables who belong to a same transaction are configured to replicate through the same replication stream, else you could be in trouble aswell

    Edited by: N K on Jan 11, 2013 6:36 AM
  • 4. Re: Common GoldenGate errors
    -joe Journeyer
    Currently Being Moderated
    Here's 2: Initializations and adding supplemental logging (for Oracle).

    1. For initializations a common mistake is to overlook transactions that are open at the time the initial load. The primary change data extract/capture needs to start at or before the time of the open transaction. Look at min(V$TRANSACTION.START_DATE) to find the date of oldest open transaction and start extract at that time - and make sure you have any needed archive logs.

    2. ORA-1403 is among the most common errors first time OGG on Oracle users see when applying data via replicat and most of the time it's because they forgot to "ADD TRANDATA" completely or added it after the that oldest date from V$TRANSACTION I just mentioned. It forces an otherwise absent PK to show up in the redo for updates that do not modify the PK.

    Good luck,
    -joe

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points