HP NonStop RDF, Руководство по управлению

Страница: 248 / 478

The RTD value reported for each updater process is the difference between the “last modified
time” of that updater's audit trail on the primary system and the timestamp added to the image
record by the extractor before sending it to the receiver. As is the case with the receiver during
an RDF takeover operation, the RTD is replaced by dots to indicate there is no RTD.
On a finely tuned RDF backup node, the RTD for an updater can regularly lag 1 to 15 seconds
behind TMF processing. However, this 15-second delay does not mean that 15 seconds are needed
to catch up; that operation might take only a few seconds.
If RDFCOM cannot connect to a particular process, RDFCOM displays dots (...) in the RTD Time,
Sequence, and Rel Byte No fields, and an appropriate file-system error number in the Error field.
Pri
The fourth column specifies the priority at which each process is running. In the RDF takeover
situation, the priority of the monitor is not reported.
Volume and Seqnce
The fifth and sixth columns together specify a file associated with each process:
• The monitor entry reflects the name of the latest MAT file to which TMF is writing
($AUDMAT.ZTMFAT.AA000056 in this example).
• Each extractor entry reflects the name of the TMF audit trail file from which it is reading
($AUDMAT.ZTMFAT.AA000056 for the master extractor and
$AUDAUX1.ZTMFAT.BB000004 for the auxiliary extractor in this example).
• The receiver entries reflect the names of the current image trail files to which each receiver
is writing ($RRCV0 write control records to $MIT and image records for updater $RUPD1
to $IMAGE0; $RRCV1 writes image records for updaters $RUPD2 and $RUPD3 to $IMAGEA1
in this example).
• The image trail entries reflect the names of the secondary image trail files to which each
receiver is writing ($RRCV0 writes image records for updater $RUPD1 to $IMAGE0; $RRCV1
writes image records for updaters $RUPD2 and $RUPD3 to $IMAGEA1 in this example).
• Each updater entry reflects the name of the secondary image file from which it is reading
($DATA03.RDF04.AA000020 for $RU01, $DATA04.RDF04.AA000003 for $RU02, and
$DATA05.RDF04.AA000003 for $RU03 in this example).
If RDFCOM cannot connect to a particular process, RDFCOM displays dots (...) in the RTD Time,
Sequence, and Rel Byte No fields, and an appropriate file-system error number in the Error field.
In the case of an RDF takeover operation, however, nothing is displayed for the Monitor's sequence
and relative byte number because those values have no relevance.
Rel Byte Addr
The column designated "Rel Byte Addr" indicates the relative byte address where the process in
question is positioned. For the extractor and updaters, it indicates where in the file that the
process is reading. For the receiver it represents where in the file that the last write operation
completed.
If RDFCOM cannot connect to a particular process, RDFCOM displays dots (...) in the RTD Time,
Sequence, and Rel Byte No fields, and an appropriate file-system error number in the Error field.
During non-takeover processing, you can observe the relative byte numbers increasing, and as
the processes finishes with a given file, you can see that the sequence number of the file increases
and that the relative byte number drops as the process starts reading at the beginning of that
next file. During a takeover or a stop-update-to-time operation when an updater has begun its
undo pass, however, you can observe that the relative byte numbers decrease. Further, when an
updater has finished with its current file, you can observe that the sequence number decreases
as the updater switches to the next file in reverse sequence and that the relative byte number
starts at the end of this next file and decreases as the updater reads backwards through the file.
248 Entering RDFCOM Commands