This situation is triggered when the average latency has
reached a warning level. Latency can also be defined in a
System Automation for z/OS policy and should match the latency
that is defined in the situation formula. The average latency
is the average elapsed time in milliseconds between the time
that transactions were committed to the source table or database
and the time that transactions were committed to the target
table or database. This average includes only the transactions
that were processed during the last polling interval.
When the situation becomes true, NetView message AQN008I
is issued as a notification for automation by the
Geographically Dispersed Parallel Sysplex® (GDPS®) solution.
When the situation is resolved (becomes false), NetView
message AQN008I is issued again as a notification for
automation by the GDPS® solution.
|
DB2 Replication: The average latency as reported by
DB2 Replication can be monitored by the IBM InfoSphere Replication
Server Q Replication Dashboard. Moving graphs in the dashboard
track real-time replication throughput, latency, and the
fullness of message queues (queue depth). You can view live
graphs that display Q Capture and Q Apply throughput, log
latency, and end-to-end latency. The dashboard summary helps
you quickly identify and troubleshoot problems, and shows
at-a-glance status information on programs, queues, Q
subscriptions, and other objects.
See the Q replication tuning
section in the IBM Information Management Software for
z/OS Solutions Information Center or DB2 Information Center
for more details.
IMS or VSAM Replication: The average latency as reported by
IMS or VSAM Replication may be higher than expected due to the following
conditions:
- Replication is restarted and there is a large amount of
pending source updates to be processed. The average latency
should return to a normal level when the backlog is processed.
- The occurrence of a large high volume batch (BMP or Batch
DL/I) window or a peak update period. The average latency
should return to a normal level once the number of source updates
to be processed has dropped and the servers have a chance
to catch up.
- Replication is started for a new subscription and the
log position is set to a time in the distant past. Latency
may appear artificially high, even though replication is
working smoothly, since replication was started from an
old log position.
Suggested IMS or VSAM Replication user actions are:
- Set the capture cache to 2G (the current max) and restart
replication.
- If the cache was already at 2G, you can let replication
run, or if the subscription allows, consider increasing the
apply PSB number for the subscription to increase parallelism.
This may require IMS or VSAM pool space and DFSPZPxx member changes.
Replication must be stopped to make this change. If the
subscription does not qualify for parallel apply, consider
creating 2 subscriptions, one with DBDs that qualify for
parallel apply and another with the DBDs that do not qualify
for parallel apply.
|