RDF System Management Manual for H-Series RVUs (RDF 1.8)

• Audit records associated with files protected by RDF
• For Enscribe files (DDL operations) only, the following file-label modification records:
— CREATE
— PURGE (if REPICATEPURGE is enabled)
— PURGEDATA
— ALTER MAXEXTENTS
• For NonStop SQL/MP and NonStop SQL/MX files (DDL operations) only, the following
file-label modification records:
— Stop-RDF-Updater records
— TMF shutdown records
— File incomplete records
— File complete records
The extractor filters out all other records and does not send them to the receiver. Among those
filtered out are audit records for volumes and files not protected by RDF (and files implicitly or
explicitly excluded by INCLUDE/EXCLUDE lists) and most of the physical audit records generated
either for block splits or during FUP RELOAD operations.
The extractor always tries to fill the buffer to be sent to the receiver. The buffer never contains
partial records; if the buffer is nearly full and the next record to be transmitted does not fit in its
entirety, the extractor transmits the current buffer and puts the record at the beginning of the
next buffer. The extractor never waits for more than one second to send data to the receiver. If
a buffer is not filled within a second, the extractor transmits the buffer (even though it is not
filled).
When the extractor has no information to send from the audit trail, it transmits a buffer containing
no audit images (an empty buffer) to the receiver. When it receives an empty buffer, the receiver
process generates an RDF control-point record in each image trail. Therefore, even when no TMF
transactions are generated on the primary system, RDF adds internal control points to the image
trail on the backup system. The file-filling rate for RDF control point records is very slow.
NOTE: Except for PURGEDATA, RDF does not replicate NonStop SQL/MP and NonStop
SQL/MX DDL operations on tables. For more information about NonStop SQL/MP and NonStop
SQL/MX DDL operations and databases on a system protected by the RDF product, see Chapter 6
(page 147) and Chapter 16 (page 295).
Although the extractor runs as a process pair, the primary process does not maintain restart
information nor checkpoint this information to its backup. Instead, the receiver maintains all
restart information for the extractor, ensuring that the extractor can be restarted. The restart point
is based on the MAT position of the last record safely stored in the image trail on the backup
system.
Whenever you start RDF, the extractor requests its starting position in the audit trail from the
receiver. Because this position is based on the audit-trail position of the last image record safely
stored in the image trail by the receiver, this method guarantees that no audit is mistakenly
omitted. If the primary extractor process fails, the backup process requests from the receiver a
new starting position in the audit trail, further guaranteeing a correct restart position. This
extractor-receiver protocol also provides protection against messages from the extractor
erroneously arriving out-of-order: if a message arrives out-of-order, the receiver directs the
extractor to restart.
When it reads from an audit-trail file, the extractor pins the file by sending a message to TMF.
Once pinned, an audit trail file remains pinned until the extractor unpins it or you issue the
following RDFCOM command at the primary system:
RDF Operations 49