Topic
2 replies Latest Post - ‏2013-05-27T08:49:03Z by S.Amarneh
DavidT
DavidT
21 Posts
ACCEPTED ANSWER

Pinned topic Q Apply with applydelay option

‏2013-05-15T16:03:43Z |

From S.Amarneh (moved from the Blog section):

Q Apply program started to delay transactions for 3 hours usign option [applydelay=10800],

messages quedued into MQ for more than 6 hours when checked MQ receive queue data using asmqmfmt utilitiy find-out that commit_time value in furure [qTransMsgHeader.commit_time: 01-08-2019 13:16:32.7102976 LOCALTIME]!!

as a work around restarted the Q Apply program without applydelay option to drain all messages from MQ then started again with applydelay option.

Does anyone faced this before? any explanation why commit_time in future?

my enviornmet is DB2 v10.1 on linux for DPF of 7 nodes, source and target runs on different servers with same configuration.

OS: SUSE Linux Enterprise Server 11 SP1

DB2 v10.1.0.0

MQ V7.5

 

asnqmfmt output of first message:

2013-05-02-17.18.40.433341 ASN0585I  "AsnQMFmt" : "" : "Initial" : The program successfully loaded the WebSphere MQ library "libmqm_r.so". Environment variable ASNUSEMQCLIENT is set to "".


**** Message number: 1
**** Message size:   888

  qMsgHeader.msgFamily:  QREP
  qMsgHeader.msgtype:    ASNMQ_TRANS_MSG
  qMsgHeader.msgVersion: ASNMQ_VERSION700
  qMsgHeader.msgFlag:
    Last message in DB transaction.
  qMsgHeader.isMultiSubTrans():     TRUE: contains multiple sub-transactions.
qTransMsgHeader.segment_num: 0001
qTransMsgHeader.commit_LSN:  5181:360f:0000:0031:0000:0000:0000:0000
qTransMsgHeader.commit_time: 01-08-2019 02:16:32.7102976 UTC
qTransMsgHeader.commit_time: 01-08-2019 13:16:32.7102976 LOCALTIME
qTransMsgHeader.nRows:       2
qTransMsgHeader.auth_id:       XXXXXX
qTransMsgHeader.auth_tkn:      
qTransMsgHeader.plan_id:       
qTransMsgHeader.uow_id:        0000:0000:0000:2e0c:744e

Thanks!

 

  • kitgo
    kitgo
    2 Posts
    ACCEPTED ANSWER

    Re: Q Apply with applydelay option

    ‏2013-05-20T15:51:55Z  in response to DavidT

    Hello,

     

    in general, the timestamp in the message is taken from the COMMIT log record processed by Q Capture at the source database.

    A few things to check for:

    1. What does 'VALUES(CURRENT_TIMESTAMP)' return?

    2. Are the clocks on every physical box the same (assuming the 7 partitions are not logical but each partition is on it's own physical box or a combination of the two) ?

     

    If the dates and CURRENT_TIMESTAMP show a correct time (i.e. a valid current date/time) for the database as well as each physical box then it's possible you have encountered a bug in replication. In this case it's probably best to open a PMR for IBM to investigate.

     

    I hope this helps.

    Thanks, Christian

    • S.Amarneh
      S.Amarneh
      1 Post
      ACCEPTED ANSWER

      Re: Q Apply with applydelay option

      ‏2013-05-27T08:49:03Z  in response to kitgo

      Hi Christian,

      system and database timestamp values are correct. i use NTP to sync system clock.

      those 7 nodes runs on one physcial server.

      already opened a PMR with IBM investigating the issue and will post results/finding when finished.

       

      Thanks for help.

      Suhaib