Results 1 to 5 of 5

Thread: Updates not getting reflected in the SQLDB although Replicate captures it

  1. #1
    akanksha.1787 is offline Junior Member
    Join Date
    Nov 2016
    Posts
    22
    Rep Power
    0

    Updates not getting reflected in the SQLDB although Replicate captures it

    Hi Experts,

    There is an issue we are facing where the changes made to the source(Oracle) DB are not getting reflected to the target (SQLDB).

    We are using the Replicate version 5.1.1.94.
    The warning we are getting is related to the primary key viz.

    " 00005668:2017-02-03T04:52:49 [ASSERTION ]W: Only a part of primary key columns werefound in an UPDATE event for table 'TROUX.APOAPPLICATIONS': found '0' from '1'columns (context000008138B7BA93F010000010000989900051F8100 C40001000008138B7BA93D)(oracle_endpoint_capture.c: 1237) :"

    Although both the source and the target tables have defined primary key as Componentid, We are not sure why is the tool looking for some sort of composite key.

    Also, the tool captures the update(if any happens to the source) and shows it in applied changes but the target table remains unchanged.

    Has this kind of tool behavior been observed earlier?
    If yes, could you let us know the possible reasons.


    Your response would be helpful.

    Regards,
    Akanksha

  2. #2
    Hein is offline Senior Member
    Join Date
    Dec 2007
    Location
    Nashua, NH - USA.
    Posts
    165
    Rep Power
    13
    Quote Originally Posted by akanksha.1787 View Post
    Hi Experts,

    >> [ASSERTION ]W: Only a part of primary key columns werefound in an UPDATE event for table 'TROUX.APOAPPLICATIONS': found '0' from '1'columns (context000008138B7BA93F010000010000989900051F8100 C40001000008138B7BA93D)(oracle_endpoint_capture.c: 1237) :"
    >> Although both the source and the target tables have defined primary key as Componentid, We are not sure why is the tool looking for some sort of composite key.
    Go into the GUI (or JSON) for TRANSFORMATION section for the identified table - TROUX.APOAPPLICATIONS
    See it the primary key flag is still set for the column 'Componentid'
    I suspect it was (accidently) dropped.
    Is the table listed as (changed)? Was it intended to be?
    Just set back the flag, or use the 'reset Table defaults' option on the bottom of the main 'Table Settings' screen if no other transformations are needed.

    Let us know how it works out?
    If trouble persists, be sure to open a support case, providing notably the Source Table DDL and Task JSON.
    Throw in the Target table for good measure, and a reptask.log fiel capturing the message.

    Regards,
    Hein.

  3. #3
    akanksha.1787 is offline Junior Member
    Join Date
    Nov 2016
    Posts
    22
    Rep Power
    0

    CDC not getting applied on the SQLDB target table

    Hi Hein ,

    Thank you for your response.

    We realized that our user does not have the Alter table access on the source database.
    I know the manual says the user should have 'ALTER ANY TABLE' access for the supplemental logging but
    do we really need 'ALTER ANY TABLE' or just ALTER on the tables being replicated?

    Our data owners are all skeptical to provide the 'Alter' accesses unless we have a proper documentation citing the need.

    We are waiting for the Alter table privilege to see if the below warning is related to the CDC failure we are getting.


    Regards,
    Akanksha

  4. #4
    Hein is offline Senior Member
    Join Date
    Dec 2007
    Location
    Nashua, NH - USA.
    Posts
    165
    Rep Power
    13
    1) Tell you DBA's that A) It is a document requirement, see your userguide. B) management bought into the solution, if they cannot grant what is needed, please have them explain to management, and step back to watch the fireworks.

    2) Did you check for the "key" flag in the transformation screen as requested?, does Replicate complain (warn I mean) about the table not having a primary key?
    Does the table have LOBs ? (Varcharm(max), XML, CLOB, BLOB...)
    Try on a table without blobs?

  5. #5
    akanksha.1787 is offline Junior Member
    Join Date
    Nov 2016
    Posts
    22
    Rep Power
    0
    Quote Originally Posted by Hein View Post
    1) Tell you DBA's that A) It is a document requirement, see your userguide. B) management bought into the solution, if they cannot grant what is needed, please have them explain to management, and step back to watch the fireworks.

    2) Did you check for the "key" flag in the transformation screen as requested?, does Replicate complain (warn I mean) about the table not having a primary key?
    Does the table have LOBs ? (Varcharm(max), XML, CLOB, BLOB...)
    Try on a table without blobs?
    Thanks for your response Hein.
    We managed to get the 'Atler' table access for the said applicaition and noticed that the changes are now not only being captured by the tool but are
    also getting reflected to the target database.

    Also, the key was properly set but it was earlier generating a warning
    "00005668:2017-02-03T04:52:49 [ASSERTION ]W: Only a part of primary key columns werefound in an UPDATE event for table 'TROUX.APOAPPLICATIONS': found '0' from '1'columns (context000008138B7BA93F010000010000989900051F8100 C40001000008138B7BA93D)(oracle_endpoint_capture.c: 1237) :"
    which is no more coming after we got the desired access.

    Moreover, we were also able to test the second approach where we requested the DBA to execute the alter statements for us to enable supplement logging.
    even that worked fine.

    Thanks & Regards,
    Akanksha

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •