RDF/IMP and IMPX System Management Manual (RDF 1.4+)

Introducing RDF
HP NonStop RDF/IMP and IMPX System Management Manual—524388-001
1-24
Purger Process
•
A modify operation is performed on the file. Modify operations are those that the
updater might perform on an open file, such as updating the file (logical
REDO/UNDO) or altering the owner or security after the replication of a file
creation.
Errors encountered are reported in the EMS event log.
If an updater process encounters a file system error, it responds in either of the
following ways (depending upon the type of error that occurred):
•
Restarts and retries the operation again by reprocessing all database updates
since the last restart point. If the updater takes this course of action, it continues to
do so until the underlying problem goes away. This would be the action, for
example, if an updater process cannot create a data file on a backup volume
because that volume is protected by the Safeguard security management
subsystem; in this case, the updater logs error message 739, with an error 48, and
restarts.
•
Skips the operation. This would be the action, for example, in response to an
error 10 (“record already exists”).
Reading Image Data
Write operations to the various sorted image trails occur asynchronously to one
another. To ensure correct operation, the updaters cannot read to the end-of-file.
Instead, they can only read as far as the receiver allows (determined by receiver “save”
points in the image trail). Thus, on a finely tuned RDF backup node, the RDF time
delay (RTD) for an updater can typically lag from 1 to 15 seconds behind TMF
processing. This 15-second delay does not mean that 15 seconds are needed for the
updater to catch up, however; that operation will typically require only a few seconds.
Purger Process
With RDF/IMP and IMPX, the updaters apply all audit records to their data volumes
regardless of whether the associated transaction has committed, has aborted, or is still
in progress.
The purging of redundant image trail files is based on transaction information.
Specifically, the receiver process maintains general information on what transactions
might be in each image file. This information is system-wide, not specific to any
particular image trail. The reasons for this pertain to performance.
First, if the receiver had to maintain specific information about what transactions were
actually represented in each image file on each image trail, the extractor-receiver
performance rate would be seriously degraded. Therefore, the receiver keeps general
information about all transactions it has seen across all trails.
Second, because considerable checking must be done across all trails to determine
what files can be purged based on what transactions might be represented in the
various files on the various image trails, the purger process performs this task.