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

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.

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.

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

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.