IBM Support

Monster transactions effect on parallel processing

Question & Answer


Question

I have two tables that use the same receive queue. One table was locked, and I received the following entries in my Q Apply log: 2010-04-13-19.35.22.060365 ASN8999D? "Q Apply" : "ASNTGT" : "BR00000" : monster deadlock 2010-04-13-19.35.22.098078 ASN8999D? "Q Apply" : "ASNTGT" : "BR00000" : (2) Processing more monster tran[64] on queue 'DB2.DATA.CAPTURE.01.REQUEST.LQ' If Q Apply encounters such a "monster" transaction, can Q Apply process other transactions in parallel?

Answer

"Monster" transaction refers to any transaction that exceeds the value of the memory_limit parameter for the replication queue map that contains the receive queue. When Q Apply encounters a monster transaction, all transactions are serialized until the monster has been applied. If the monster transaction is deadlocked (because of the lock on the table), other transactions in the receive queue are not processed. If both tables use the same receive queue, the second update on the table is still in the receive queue waiting to be applied.

In order to reduce monster transactions, increase the memory_limit setting for the replication queue map that contains the receive queue to 32MB or 64MB. The memory_limit value is stored in the IBMQREP_RECVQUEUES table.

[{"Product":{"code":"SSDP5R","label":"InfoSphere Replication Server"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Q Apply","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1;9.1.1;9.1.1.2;9.5;9.7;9.7.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
16 June 2018

UID

swg21428584

Page Feedback