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

NOTE: You must be sure that volumes on the primary system containing alternate key files and
indexes are protected by RDF. It is not sufficient to protect just the associated data file or table
(particularly in the case of alternate keys). Likewise, if primary partitions reside on volumes protected
by RDF, you must ensure that the secondary partitions are also configured for protection.
File System Errors Involving Data Files
File system errors can occur when:
• A file is created.
• A file is opened.
• 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”).
RTD Times
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 RTD time (relative time delay) for an updater can typically indicate
that the updater is 1 to 15 seconds behind TMF processing on the primary system. This 15-second
delay does not mean that 15 seconds are needed for the updater to catch up; catching up typically
requires less than a second. See the discussion on RTD Times in “RDF States” (page 102)
Purger Process
The purger process is responsible for purging image trail files when they are no longer needed.
When the RDF configuration protects data volumes configured to auxiliary audit trails, then the
purger process creates a series of files prefixed by CC, to facilitate purging of files. The CC files
correlate auxiliary image trails to the master image trail. Similar to AA and BB files, CC files also
have the nomenclature CCnnnnnn, where nnnnnn is the number value in the range 000001 to
999999. The default extent size for CC files is 16, 16 and cannot be altered by the user.
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.
40 Introducing RDF