Topic
  • 4 replies
  • Latest Post - ‏2013-03-07T06:45:59Z by Rphilo
JorgeTuzi
JorgeTuzi
8 Posts

Pinned topic DataMirror 6.1 in Iseries, Refresh is OK but problems with mirroring

‏2013-03-01T14:53:45Z |
 I installed Datamirror 6.1 over Iseries and I have just made a refresh of a table, but when the suscription is running in "mirroring" mode and we insert, delete or update any record in the source table, there is no news in the target table. I have just revised everything but we couldn't find anything wrong. do you have any idea? 
 
Thanks in advance!!!
 
Jorge
Updated on 2013-03-07T06:45:59Z at 2013-03-07T06:45:59Z by Rphilo
  • Rphilo
    Rphilo
    391 Posts

    Re: DataMirror 6.1 in Iseries, Refresh is OK but problems with mirroring

    ‏2013-03-04T12:15:32Z  
     Jorge
     
    There are a number of possibilities
     
    1) The tables are still in active pending status., This happens if you perform mark table capture point- CDC will ignore any changes it scrapes before the time you do the mark table capture point, You can tell if this is the case
                           a) The event log has messages "table xyz is ready to be mirrored" indicates active pending status", instead of "table xyz is being mirrored"
                           b) the event log has messages " mirroring initiated for table xyz" when the time of the mark table capture point is reached in the journl
                            c) If the tables are still in active pending status, you can query <product library/dmfs510p and review the updsts column
                                                                 0 = idle
                                                                 1= refresh
                                                                  2=active pending
                                                                  3-active (capturing changes)
                                                                   4-active ignore (during refresh while active)
                           d) If you display the journal and you see user entries (posted by CDC) of type \C. CDC posts these when mark table capture point is done, so you can read the journal to determine what CDC has done.[CDC also uses \b and \c user entries to mark the start and end of refresh in the journal, so if you only have user entries  \c without \b as well, then you have done mark table capture point)
     
    2) CDC is starting mirroring from the "wrong" position, i.e. you have manually set the bookmark with SETJRNPOS- the source event log will tell you where it started from
    3) You are running CDC under commitment control and you have not issued a commit on the source (the target event log will tell you whether CDC is replicating under commit control or not)
    4) You have disabled CDC operations on the target table (review column mappings/operations tab)
    5) You have a row filter in place which is not working for mirroring
    6) You have an error in the target event log or source event log
    7) You have a user exit on the target side and you are not physically saving updates to the target tables until either a high number of updates are pending or the apply job ends. Review the file description on the target (if iSeries) and set to force write ratio to 1
     
    My money is on cause 1.
     
    If you perform a refresh before mirroring, ensure that you set the status to refresh and then start mirroring, CDC will refresh the tables and then automatically start mirroring from the correct position without further intervention from the operator.
     
    Regards
     
    Robert
  • JorgeTuzi
    JorgeTuzi
    8 Posts

    Re: DataMirror 6.1 in Iseries, Refresh is OK but problems with mirroring

    ‏2013-03-06T19:08:00Z  
    • Rphilo
    • ‏2013-03-04T12:15:32Z
     Jorge
     
    There are a number of possibilities
     
    1) The tables are still in active pending status., This happens if you perform mark table capture point- CDC will ignore any changes it scrapes before the time you do the mark table capture point, You can tell if this is the case
                           a) The event log has messages "table xyz is ready to be mirrored" indicates active pending status", instead of "table xyz is being mirrored"
                           b) the event log has messages " mirroring initiated for table xyz" when the time of the mark table capture point is reached in the journl
                            c) If the tables are still in active pending status, you can query <product library/dmfs510p and review the updsts column
                                                                 0 = idle
                                                                 1= refresh
                                                                  2=active pending
                                                                  3-active (capturing changes)
                                                                   4-active ignore (during refresh while active)
                           d) If you display the journal and you see user entries (posted by CDC) of type \C. CDC posts these when mark table capture point is done, so you can read the journal to determine what CDC has done.[CDC also uses \b and \c user entries to mark the start and end of refresh in the journal, so if you only have user entries  \c without \b as well, then you have done mark table capture point)
     
    2) CDC is starting mirroring from the "wrong" position, i.e. you have manually set the bookmark with SETJRNPOS- the source event log will tell you where it started from
    3) You are running CDC under commitment control and you have not issued a commit on the source (the target event log will tell you whether CDC is replicating under commit control or not)
    4) You have disabled CDC operations on the target table (review column mappings/operations tab)
    5) You have a row filter in place which is not working for mirroring
    6) You have an error in the target event log or source event log
    7) You have a user exit on the target side and you are not physically saving updates to the target tables until either a high number of updates are pending or the apply job ends. Review the file description on the target (if iSeries) and set to force write ratio to 1
     
    My money is on cause 1.
     
    If you perform a refresh before mirroring, ensure that you set the status to refresh and then start mirroring, CDC will refresh the tables and then automatically start mirroring from the correct position without further intervention from the operator.
     
    Regards
     
    Robert
     Thank so much Robert!!!, I will take in account your recomendation, after that I will teel you
  • JorgeTuzi
    JorgeTuzi
    8 Posts

    Re: DataMirror 6.1 in Iseries, Refresh is OK but problems with mirroring

    ‏2013-03-06T21:57:52Z  
    • Rphilo
    • ‏2013-03-04T12:15:32Z
     Jorge
     
    There are a number of possibilities
     
    1) The tables are still in active pending status., This happens if you perform mark table capture point- CDC will ignore any changes it scrapes before the time you do the mark table capture point, You can tell if this is the case
                           a) The event log has messages "table xyz is ready to be mirrored" indicates active pending status", instead of "table xyz is being mirrored"
                           b) the event log has messages " mirroring initiated for table xyz" when the time of the mark table capture point is reached in the journl
                            c) If the tables are still in active pending status, you can query <product library/dmfs510p and review the updsts column
                                                                 0 = idle
                                                                 1= refresh
                                                                  2=active pending
                                                                  3-active (capturing changes)
                                                                   4-active ignore (during refresh while active)
                           d) If you display the journal and you see user entries (posted by CDC) of type \C. CDC posts these when mark table capture point is done, so you can read the journal to determine what CDC has done.[CDC also uses \b and \c user entries to mark the start and end of refresh in the journal, so if you only have user entries  \c without \b as well, then you have done mark table capture point)
     
    2) CDC is starting mirroring from the "wrong" position, i.e. you have manually set the bookmark with SETJRNPOS- the source event log will tell you where it started from
    3) You are running CDC under commitment control and you have not issued a commit on the source (the target event log will tell you whether CDC is replicating under commit control or not)
    4) You have disabled CDC operations on the target table (review column mappings/operations tab)
    5) You have a row filter in place which is not working for mirroring
    6) You have an error in the target event log or source event log
    7) You have a user exit on the target side and you are not physically saving updates to the target tables until either a high number of updates are pending or the apply job ends. Review the file description on the target (if iSeries) and set to force write ratio to 1
     
    My money is on cause 1.
     
    If you perform a refresh before mirroring, ensure that you set the status to refresh and then start mirroring, CDC will refresh the tables and then automatically start mirroring from the correct position without further intervention from the operator.
     
    Regards
     
    Robert
    Robert: I have been analyzing the issue when I found this message:
     
     Table [TABLE NAME] in library [LIBRARY NAME] has no unique index assigned and an Update transaction has been sent from the source.
     
     In the knowledge database ( http://www-01.ibm.com/support/docview.wss?uid=swg21572524) I found the same issue posted with the solution:
     

    Cause

    Missing unique index on the target table (after which remapping has to be done).

     

    Resolving the problem

    Error can be fixed with the following steps:

    1) Create an unique index on the target table.
    2) Remap the source table to the target table in Management Console.

     
    It was confusing becouse the refresh process finished right, the insert during mirroring process finished right, but the update and delete were failed. I will tell you if this solution is true for this problem.
     
    thanks again!!!
     
     
  • Rphilo
    Rphilo
    391 Posts

    Re: DataMirror 6.1 in Iseries, Refresh is OK but problems with mirroring

    ‏2013-03-07T06:45:59Z  
    • JorgeTuzi
    • ‏2013-03-06T21:57:52Z
    Robert: I have been analyzing the issue when I found this message:
     
     Table [TABLE NAME] in library [LIBRARY NAME] has no unique index assigned and an Update transaction has been sent from the source.
     
     In the knowledge database ( http://www-01.ibm.com/support/docview.wss?uid=swg21572524) I found the same issue posted with the solution:
     

    Cause

    Missing unique index on the target table (after which remapping has to be done).

     

    Resolving the problem

    Error can be fixed with the following steps:

    1) Create an unique index on the target table.
    2) Remap the source table to the target table in Management Console.

     
    It was confusing becouse the refresh process finished right, the insert during mirroring process finished right, but the update and delete were failed. I will tell you if this solution is true for this problem.
     
    thanks again!!!
     
     
     Hi Jorge
     
    The cause and suggested solution are certainly appropriate. I am glad that you found the reason, In most cases the source and target replication/subscription event logs will indicate the cause of any problems.
     
    In the present case, the refresh process will be successful without a unique index on the iSeries target as it is only doing inserts, and any insert mirrored from the source will be successful. However the first time you have an update or delete transaction, the iSeries target apply will fail as it needs the unique key to perform the look-up of the row to update or delete.
     
    Regards
     
    Robert