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

command (only those updaters that did not generate a message 733 are started). Check the RDF
log again to see if RDF generated another message 905. If it did, issue another START RDF,
UPDATE ON command, and so forth, until RDF logs a message 908. When RDF logs the message
908, do the Steps 2 and 3 listed above.
RDF does not support shared access NonStop SQL/MP DDL operations where the target file is
located on a different node than the primary system. For example, if you have two RDF
subsystems, one going from system \A to system \B and the other going from system \X to
system \Y, you cannot move a partition boundary for a table on
system \A keeping half of the table on system \A and moving the other half to a table on system
\X because RDF on system \X does not know about the shared access NonStop SQL/MP DDL
operation (the Stop-RDF-Updater audit records for the operation on system /A go to system /B,
not to system /Y).
Network Configurations and Shared Access NonStop SQL/MP DDL Operations
Under certain circumstances, takeover network undo processing after having performed a shared
access NonStop SQL/MP DDL operation can lead to an abort with database corruption.
You can, however, avoid that situation entirely by using the protocol described in “Network
Configurations and Shared Access NonStop SQL/MP DDL Operations” (page 283) when
performing shared access NonStop SQL/MP DDL operations in a network environment:
RDF and NonStop SQL/MX Operations
For information about replicating NonStop SQL/MX objects, see Chapter 16 (page 295).
Backing Up Image Trail Files
The RDF image trail files exist strictly for use by the receiver, purger, and updater processes,
and should not be explicitly opened by RDF users for any reason, including backup to tape. Once
the receiver has processed an image file, this file might no longer serve a purpose (except in the
case of triple contingency, where the file might be used in a COPYAUDIT operation). In particular,
image files are not like TMF audit dump files; they cannot be used to restart RDF in the same
way that audit files are used to restart TMF. Typically, image files should only be accessed by
RDF itself or by RDF specialists and support people.
However, if you do want to back up image trail files at your site, you should be aware of the
way RDF accesses these files and the ramifications of this access. When the receiver updates an
image trail file, it opens that file with shared read/write access. When updaters read audit
information from an image trail file and apply it to the backup database, they open the image
trail file with shared read-only access. When the RDF purger process determines that a particular
image trail file is no longer needed by any updater, it purges that file unless the current
RETAINCOUNT precludes doing so. If you want to back up an image trail file, you should hold
that file open to prevent the purger from purging it until your backup is complete.
For a successful backup, follow these steps:
1. Execute a process that opens the image trail file with shared read access. This can be a simple
process that you supply to perform only this operation. When the purger determines that
all updaters are finished with this image trail file (named, say, AA000007), and have moved
on to the next image trail file (named, say, AA000008), then it might try to purge AA000007.
The purge operation will fail, however, because your process still has AA000007 open. The
purger will terminate the purge attempt and try it again later. As long as your process keeps
AA000007 open, the purger cannot purge it.
2. When the purger tries to purge AA000007 and fails, it writes a message denoting this error
to the EMS event log. This message implies that all updaters have moved from AA000007
to AA000008 (or beyond), and will never need AA000007 again; it is your only way to know
RDF and NonStop SQL/MX Operations 143