HP NonStop RDF, Руководство по управлению

Страница: 153 / 478

again checks 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 303) 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 323) .
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 153