Results 1 to 6 of 6
  1. #1
    Join Date
    Dec 2004
    Posts
    2

    Thumbs down Unanswered: DB2 Replication Problem

    Hello

    I have problem with replication in DB2 fixpack 7a so I have DB2 8.2.
    The problem is platform independent. I tested on AIX 5.2 and on Windows XP.

    For defining replication I use Replication Center.

    I create capture and apply control tables in database for instance sample.
    Then I register table for replication, for example my favorite staff.
    Then I create apply qualifier and define user-copy replication (copy 1 by 1).

    Next I create asnpwd.aut file and start capture
    asncap capture_server=sample capture_schema=asn

    and start apply
    asnapply control_server=sample apply_qual=test

    The normal full refresh is done. And the replication works.
    Then I stop capture and apply by commands asnacmd and asnccmd.

    and stop instance

    and try do start replication.

    The capture starts ok. But apply is not health. It's started but permanently
    create and delete temporary file <apply_qual.000> with size of 0 byte and uses 100% of CPU.

    Martin Pozdilek

  2. #2
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Check the replication log files. If you can't find them, then specify the location when you use asnapply and asncapture.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  3. #3
    Join Date
    Dec 2004
    Posts
    2
    Quote Originally Posted by Marcus_A
    Check the replication log files. If you can't find them, then specify the location when you use asnapply and asncapture.
    The logs are absolutly clean. It was the first, I have checked. I didn't found anywhere any error. OS is ok, db2diag.log is ok, filesystems are large enough, I hope that rights for files are ok. I just only restart instance.

    Capture logs :

    2004-12-08-22.42.54.108000 <asnParmClass:rintParms> ASN0529I "Capture" : "ASN" : "Initial" : The value of "STARTMODE" was set to "WARMSI" at startup by the following method: "IBMSNAP_CAPPARMS".
    2004-12-08-22.42.54.108000 <Asnenv:setEnvIpcQRcvHdl> ASN8008D "Capture" : "ASN" : "Initial" : "Created" IPC queue with key(s) "(OSSEIPC48tempDB2.SAMPLE.ASN.CAP.IPC, OSSEIPC49tempDB2.SAMPLE.ASN.CAP.IPC, OSSEIPC50tempDB2.SAMPLE.ASN.CAP.IPC)".
    2004-12-08-22.42.54.568000 <CWorkerMain> ASN0100I CAPTURE "ASN" : "WorkerThread". The Capture program initialization is successful.
    2004-12-08-22.42.54.568000 <CWorkerMain> ASN0109I CAPTURE "ASN" : "WorkerThread". The Capture program has successfully initialized and is capturing data changes for "1" registrations. "0" registrations are in a stopped state. "0" registrations are in an inactive state.


    Apply log end s with :
    2004-12-08-22.38.19.913000 <asnParmClass:rintParms> ASN0529I "Apply" : "TEST" : "Initial" : The value of "INAMSG" was set to "Y" at startup by the following method: "DEFAULT".
    2004-12-08-22.38.20.064000 <Asnenv:setEnvIpcQRcvHdl> ASN8008D "Apply" : "TEST" : "Initial" : "Created" IPC queue with key(s) "(OSSEIPC48tempDB2.SAMPLE.TEST.APP.IPC, OSSEIPC49tempDB2.SAMPLE.TEST.APP.IPC, OSSEIPC50tempDB2.SAMPLE.TEST.APP.IPC)".
    2004-12-08-22.38.20.074000 <CPCIMPC(08/07)> ASN1045I APPLY "TEST" : "Initial". The Apply program was started using database "SAMPLE".

    In normal way, the apply should write to log following row, but he create and remote file in infinitive loop.

    2004-12-08-22.34.59.686000 <CPREST(01/00)> ASN1044I APPLY "TEST" : "WorkerThread". The Apply program will become inactive for "3" minutes and "0" seconds.

  4. #4
    Join Date
    Nov 2004
    Posts
    23
    Hello Martin!

    I am sorry for mine poor English!

    I have DB2 UDB 8.2 for Win2000 (after fixpack 7a).

    I had similar problem. I have not found precise explanation to this (there can be it a bug), but I can tell the following, if IBMSNAP_SUBS_SET.MAX_SYNCH_ MINUTES > = IBMSNAP_SUBS_ SET.SLEEP_ MINUTES, after startup Apple when in the source table there were no changes from the moment of the latter it of startup, it(Apply) begins to work just as you have described. But as soon as Apply will apply the new data to the target table after respective changes in the source table, it(Apply) begins to work normally. And such behaviour will take place always.

    Therefore as workaround, do not use the block factor (MAX_SYNCH_ MINUTES must be null) before obtaining explanations from IBM , if you until now use it.

    I hope it to you will help.

    Best regards, Dmitriy.
    Last edited by kdima71; 12-10-04 at 06:19.

  5. #5
    Join Date
    Nov 2004
    Posts
    374

    replication

    sleep minutes is the time between cycles of apply
    max_synch... : time to check between logmarkers to have smaller cycles of apply (similar as commitcount, but based on time and not nbr of rows)
    if nothing todo : apply will always check the cd tables for small intervals, and busy many times (using resources)
    Hope this will help
    Best Regards, Guy Przytula
    Best Regards, Guy Przytula
    DB2/ORA/SQL Services
    DB2 DBA & Advanced DBA Certified
    DB2 Dprop Certified
    http://users.skynet.be/przytula/dbss.html

  6. #6
    Join Date
    Nov 2004
    Posts
    23
    Hello, Guy Przytula!

    1. You want to tell, what the problem not in it (is used the block factor)?Then in what?
    2. Whether there are at you any offers on the solution of this problem?
    3. It seems, that it is a bug DB2 UDB 8.2. If I am mistaken, I shall be grateful for any explanations!

    Best regards, Dmitriy.

Posting Permissions

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