24 WebSphere Replication Server for z/OS Using Q Replication: High Availability Scenarios for the z/OS Platform
Each of these measures is discussed in further detail in the following sections.
2.4.1 Q Capture latency
Q Capture latency measures the difference between a given point in time and the timestamp
of the last committed transaction that Q Capture read. This measure uses the values of the
MONITOR_TIME and CURRENT_LOG_TIME columns in the IBMQREP_CAPMON control
table. When examined in aggregate, these latency measurements can help you determine
how well a Q Capture program is keeping up with the database log.
For example, if a Q Capture program inserted a row of performance data into the
IBMQREP_CAPMON table (MONITOR_TIME) at 10 a.m. and the timestamp of the last
committed transaction (CURRENT_LOG_TIME) is 9:59 a.m., then the Q Capture latency
would be one minute.
If the Q Capture latency is considered too high, log-reading performance may be improved by
creating an additional Q Capture schema and moving some Q subscriptions or XML
publications to the new schema. Each additional schema has its own transaction thread to
read the log.
2.4.2 Q Capture transaction latency
Q Capture transaction latency measures the time between the Q Capture program reading
the commit statement for a transaction in the DB2 recovery log, and the message containing
the transaction being put on a send queue. This statistic provides information about how long
it takes the Q Capture program to reassemble transactions in memory, filter out rows and
columns based on settings for the Q subscription or XML publication, and then put the
transaction messages on a queue.
If this latency is considered too high, it may be reduced by:
򐂰 Increasing the value of the MEMORY_LIMIT parameter, which sets the total amount of
memory allocated by a Q Capture program. This only helps with large transactions that
spill to disk during Q Capture.
򐂰 Raising the MAX_MESSAGE_SIZE parameter, which is defined when you create a
replication queue map or publication queue map. This parameter sets the amount of
memory that a Q Capture program allocates for building transaction messages for each
send queue. If the maximum message size is too small, the Q Capture program divides
Attention: Any latency measure that involves transactions that are replicated between
remote Q Capture and Q Apply servers can be affected by clock differences between the
source and target systems. To get a true measure, ensure that the clocks are
synchronized. Also, achieving good latency requires the Q Capture and Q Apply programs
to run continuously.
Note: In a z/OS data sharing environment, an additional Q Capture schema may add to
CPU consumption as well as latency.
Note: In an upcoming PTF PK14999, the recommendation will be to set the
MEMORY_LIMIT to zero and let Q Capture optimize the MEMORY_LIMIT from the
region size.

Get WebSphere Replication Server for z/OS Using Q Replication: High Availability Scenarios for the z/OS Platform now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.