WebSphere Replication Server for z/OS Using Q Replication: High Availability Scenarios for the z/OS Platform

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.