Forum Stats

  • 3,816,290 Users
  • 2,259,165 Discussions
  • 7,893,442 Comments

Discussions

Replicat ABENDS with "MAPPING ERROR" even with new SOURCDEFS

User_5Y70F
User_5Y70F Member Posts: 25 Red Ribbon
edited Dec 12, 2018 7:26AM in GoldenGate

Hello,

SOURCE:

Oracle 12c

OGG 12.3

Oracle Linux 7 x64

TARGET:

MSSQL 2014 Std

OGG 12.3

Windows Server 2016

ISSUE:

The customer changed 1 column data type in source DB, and this caused the REPLICAT on target to ABEND with:

WARNING OGG-01431  Aborted grouped transaction on SCHEMA.VEHICLE_ORDER, Mapping error.WARNING OGG-01003  Repositioning to rba 75954 in seqno 3.WARNING OGG-01151  Error mapping from SCHEMA.VEHICLE_ORDER to SCHEMA.VEHICLE_ORDER."ERROR   OGG-01296  Error mapping from SCHEMA.VEHICLE_ORDER to SCHEMA.VEHICLE_ORDER.

1 column, named "EXTERNAL_REFERENCE" datatype was changed from VARCHAR2 to NUMBER. In MSSQL Target, the data type was VARCHAR(50), so as a result, I changed this to DECIMAL(38,0).

I then regenerated my definitions file on source and transferred them to target.

I updated the REPLICAT PARAM file to reference new definitions (I am using NO_USE_TRAILDEFS in my GLOBALS PARAMS, to force use of .def file in REPLICATE in OGG 12.3)

I restart REPLICAT on target but it still abends with the same error... Have I missed something? Or is it likely that the customer has actually changed more than that one column. (Thats all they tell me they have changed, but I'm not too sure if I trust that information...)

Any suggestions or help is appreciated. Thanks.

Tagged:
Vikas Panwar

Best Answer

  • K.Gan
    K.Gan Member Posts: 2,755 Bronze Crown
    edited Nov 29, 2018 7:27PM Answer ✓

    The issue with DDL changes for heterogeneous replication is that you need to coordinate the timing of the change. briefly, you stop all transactions to this table by stopping your application, locking the table whatever. Then make sure the replicat has progressed past the time you have the table to yourself, then stop the extract and replicat, make your change to the table, edit the param of replicat with the new sourcedef then start extract and replicat.

    What happens here is that you have a mix of old and new structured in the trail record. Your target table is now changed, together with the new sourcedef and the old trail record is now 'wrong'. Put back the old sourcedef and change your target table back to what it was. Let it rn for a while, when the new record is encountered replicat will abend, then put in the new stuff.

    Cheers

    Kee

    User_5Y70FVikas Panwar

Answers

  • K.Gan
    K.Gan Member Posts: 2,755 Bronze Crown
    edited Nov 29, 2018 7:27PM Answer ✓

    The issue with DDL changes for heterogeneous replication is that you need to coordinate the timing of the change. briefly, you stop all transactions to this table by stopping your application, locking the table whatever. Then make sure the replicat has progressed past the time you have the table to yourself, then stop the extract and replicat, make your change to the table, edit the param of replicat with the new sourcedef then start extract and replicat.

    What happens here is that you have a mix of old and new structured in the trail record. Your target table is now changed, together with the new sourcedef and the old trail record is now 'wrong'. Put back the old sourcedef and change your target table back to what it was. Let it rn for a while, when the new record is encountered replicat will abend, then put in the new stuff.

    Cheers

    Kee

    User_5Y70FVikas Panwar
  • User_5Y70F
    User_5Y70F Member Posts: 25 Red Ribbon
    edited Dec 12, 2018 7:26AM

    Hi K.Gan,

    Thankyou for the clarification. I see how the process should work now. The issue is that it's the end user/customer changing tables, and they do so without consulting us (the provider of the Oracle services they use). This is clearly something we have to overcome ourselves, but thankyou anyway for clarifying.