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

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 detailed in the previous discussion, RTD times are not precise. They represent a
general figure of how far the updater might be delayed. The RTD times are useful value, but
do not consider them as as precision indicators of how far an RDF process is delayed. Further,
the RTD times 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 might only take 15 seconds to catch up.
Updaters typically show RTD times that cycle from 0 to 20 seconds, an updater typically takes
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.
• Volume and Seqnce together specify a file associated with each process:
The monitor entry reflects the name of the MAT file to which TMF is writing
($AUDIT.ZTMFAT.AA000056 in this example).
Each extractor entry reflects the name of the TMF audit trail file that it is reading
($AUDIT.ZTMFAT.AA000056 for the master extractor and $DATA17.ZTMFAT.BB000004
for the auxiliary extractor in this example).
The master receiver entry reflects the name of the master image trail file
($MIT.RDF04.AA000044) to which it is writing. Please note that only TMF and RDF control
records are written to the master image trail (MIT).
The image trail entries reflect names of the secondary image trail files to which the
corresponding receiver has written image data (the master receiver writes MAT-based image
records to $IMAGE0.RDF04.AA000022 and the receiver $RRCV1 writes to AUX01-based
image records to $IMAGEA1.RDF04.AA000003 in this example).
Each updater entry reflects the name of the secondary image file from which it is reading
($IMAGE0.RDF04.AA000022 for $RUPD1, $IMAGEA1.RDF04.AA000004 for $RUPD2,
and $RUPD3 in this example).
• Rel Byte Addr specifies where in the specified file the particular process is either writing
(receivers) or reading (extractors and updaters).
• Cpus specifies the CPUs in which each process pair is running.
• Error lets you know if a process has experienced an error. If the column is blank, no error
has occurred. If the column for an updater contains asterisks (****), the updater has
experienced a critical error. If the updater is doing an undo pass, the word undo appears in
the Error column. If the Updater is suspended during an NSA operation on the primary, the
word “SUSP” appears in the Error column for that updater. If RDFCOM cannot reach a
particular process, the error column for that process contains the applicable file-system error
number that RDFCOM encountered while attempting to send to that process.
The occurrence of a critical error could mean that the backup database is no longer
synchronized with the primary database because of data loss. If asterisks appear in the Error
104 Operating and Monitoring RDF