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

to see all updaters have processed all image audit up to this special record. When the purger
generates the RDF event 908, you are now ready to perform steps 2 and 3 above.
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. Consider an example where
you gave a Table X on your RDF primary system \A and you want to create a new partition for
the table on \B. It makes no difference whether you have an RDF network configured or not because
RDF cannot support a Shared Access operation where the target of the operation is on a different
node. The reason for this is that TMF only generates the Stop-RDF-Updaters record on the node
where the source object of the operation is performed, in this case on \A. This means that even if
the target node of the operation is also RDF protected, there is simply no way to coordinate updaters
to shutdown on the backup of the target node because that Stop-RDF-Updaters record is never 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, this product only replicates the DDL
change when it sees that RDF has generated the 908 event. When it finishes the DDL operation
on the backup system, it automatically restarts the updaters. Thus the use of 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 286) 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 307).
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:
144 Critical Operations, Special Situations, and Error Conditions