RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

are associated with the MAT, while the extractor $$REXT1 and receiver $RRCV1 are associated
with auxiliary audit trail AUX01.
Because of insufficient space, however, ATINDEX values are not displayed explicitly for updaters.
To determine the ATINDEX value of a particular updater, see the ATINDEX value of the updater's
specific image trail.
In this example, a monitor process and two extractor processes are configured on the primary
system, and two receiver processes and three updater processes are configured on the backup
system. For each process, the following items appear, indicated by column headings near the top
of the display:
• RDF Process identifies the type of process. Notice that each updater process is identified
by the name of the primary volume the updater is protecting and the corresponding volume
on the backup system. In this example, each volume being updated on the backup system has
the same name as the corresponding volume on the primary system (for example, updates to
the volume $DATA07 on the primary system are replicated by the updater process $RUPD2
to the volume $DATA07 on the backup system).
• Name denotes the name assigned to the process.
• RTD Time specifies the current RDF time delay (RTD) value for the extractor process, receiver
process, and all updater processes. These values can help you determine how far behind the
applications each process is running.
In every audit trail, there are different timestamps that are observed by the extractor reading
that trail. The RTD value of an extractor corresponds to the difference between the last
modification timestamp of the latest audit trail file in the audit trail being read by the extractor
and the latest timestamp that extractor encountered within the audit trail. The extractor also
stores the latest timestamp taken from the audit trail in each audit record, which is then defined
as an image record.
The receiver RTD time virtually always mirrors that of the extractor sending to it. The only time
it varies is during a receiver restart condition. The value of this RTD time has to a large part
become obsolete, but it continues to be displayed for long standing continuity with older RDF
releases.
The RTD value reported for each updater process is the difference between the “last modified
time” of the latest file in the audit trail to which the volume protected by the updater is
configured and the timestamp from the latest image record that the updater has read.
The RTD value reflects, in the most general sense, the amount of time by which the backup
database is behind the primary database. In the example shown earlier in this command
description, the specified RTD time for the updater $RUPD1 is 0 minutes and 6 seconds,
meaning that the updater is running approximately 6 seconds behind the MAT on the primary
system. On a finely tuned RDF backup node, the RTD for an updater can typically vary between
1 and 20 seconds behind TMF processing.
NOTE: As can be seen from the discussion above, RTD times are not precise. They represent
a general figure of how far the updater might be behind. In this sense they have value, but
they should not be taken as precision indicators of how far an RDF process has fallen behind.
Further, they do not at all reflect how long it will take the RDF process to catch up. For example,
an extractor that shows it is 30 minutes behind may only take 15 seconds to catch up. Updaters
typically show RTD times that cycle from 0 to 20 seconds, but it typically takes an updater a
fraction of one second to catch up and show an RTD time of 0:00 before it starts to cycle back
up to 15-20 seconds.
• Pri specifies the priority at which each process is running.
106 Operating and Monitoring RDF