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

1: 0164$TPURPPurger
susp1: 0104448012$SWAP01165$MU$DATA01->$FC0000
CAUTION: While the NonStop SQL products allow a DDL change with Shared Access where
the target is located on a different node, RDF does not support this occurrence. For example, you
assigned a Table X on your RDF primary system \A and you want to create a new partition for
the table on \B. Even if you have an RDF network configured, RDF cannot support a Shared Access
operation where the target of the operation is on a different node. The reason that RDF cannot
support this operation is that TMF only generates the Stop-RDF-Updaters record on the node where
the source object of the operation is performed, which, in this case, is on \A. Therefore, even if
the target node of the operation is also RDF protected, you cannot coordinate updaters to shut
down on the backup of the target node, because the Stop-RDF-Updaters record is not seen by the
updaters on the RDF backup system of \B.
NOTE: If you use the NonStop SQL DDL Replicator product to replicate your NonStop SQL/MP
DDL changes that include the WITH SHARED ACCESS option, RDF only replicates the DDL change
when it sees that RDF has generated the 908 event. When RDF finishes the DDL operation on the
backup system, it automatically restarts the updaters. Therefore, using this product can simplify
your manual operations.
Network Configurations and Shared Access NonStop SQL 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 293) when performing
shared access NonStop SQL/MP DDL operations in a network environment:
RDF and NonStop SQL/MX Operations
For particular information about replicating NonStop SQL/MX objects, see Chapter 16 (page 316).
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 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 image records from
an image trail file and apply them 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:
RDF and NonStop SQL/MX Operations 143