HP NonStop RDF J-series RVUs Management Manual page 115

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.
• 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 RDFCOM cannot reach a particular process, the Error column for that
process contains the applicable file-system error number that RDFCOM encountered when
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
Performing Routine Operational Tasks 115