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

6. At the backup system, use the RESTORE utility to place the objects on the backup system,
specifying the ANSI names for the backup system. Use the LOCATION clauses to have RESTORE
place the objects in the correct Guardian locations. See “Restoring to a Specific Location” for
general restore syntax for NonStop SQL/MX databases.
For example, assume you have the objects on your primary system that have these fully qualified
Guardian names:
\pnode.$DATA01.ZSDABCDEF.FILE100
\pnode.$DATA02.ZSDABCDEF.FILE100
\pnode.$DATA03.ZSDABCDEF.FILE100
For the RESTORE command, you must name the qualified Guardian filenames of your source
objects and also the qualified Guardian filenames of your target objects in the LOCATION
clause.
LOCATION
( \pnode.$DATA01.ZSDABCDEF.FILE100 TO \bnode.$DATA0A.ZSDABCDEF.FILE100,
\pnode.$DATA02.ZSDABCDEF.FILE100 TO \bnode.$DATA0B.ZSDABCDEF.FILE100,
\pnode.$DATA03.ZSDABCDEF.FILE100 TO \bnode.$DATA0C.ZSDABCDEF.FILE100
)
The volume names can differ between the primary and backup systems. Also, the subvolume
and filenames on the backup system must be identical to those on the primary system, and
the subvolume must correspond to the subvolume you used when you created your schema.
The backup database is now ready for RDF replication activity.
Online Database Synchronization With NonStop SQL/MX Objects
The principles of protocol for online database synchronization with NonStop SQL/MX objects are
the same as for Enscribe and NonStop SQL/MP objects. That is, you follow the guidelines for the
RDF online database-synchronization protocol. The only difference is how the fuzzy copy is obtained.
The following discussions focus on the two options for getting the fuzzy copy: creating a fuzzy
copy on the primary system or creating the fuzzy copy on the backup system. Please note, however,
that the method of taking an online dump and then the use of TMF File Recovery to a New Location
(FRNL) is an alternative to getting a fuzzy copy than the method below, and this is discussed in
Chapter 7.
Creating the Fuzzy Copy on the Primary System
The advantage of this method is that in creating and populating the fuzzy copy on the primary
system you achieve better performance than by creating and populating the fuzzy copy over the
network. Once created and populated, you use BACKUP/RESTORE to move the fuzzy copy to the
backup system. The disadvantage of this method is that it requires disk space on the primary system
to store a second copy of your NonStop SQL/MX database.
To create the fuzzy copy on the primary system, perform these steps.
1. Create a temporary catalog on your primary system to correspond to your regular catalog on
your primary system whose objects you want RDF to replicate.
CREATE CATALOG catalog_name LOCATION optional_guardian_location;
2. Create a temporary schema for your temporary catalog. Follow the instructions in “Creating
a NonStop SQL/MX Backup Database From an Existing Primary Database” (page 310), but
be sure to perform the instructions on your primary system instead of on the backup system.
The name of the temporary schema must be identical to the name of the schema whose objects
you want replicated. You must also ensure that the subvolume name for the temporary schema
is identical to that of the schema whose objects you want replicated.
3. Create temporary objects in your temporary schema. Follow the guidelines outlined in “Creating
a NonStop SQL/MX Backup Database From an Existing Primary Database” (page 310), except
that you must create these temporary objects on the primary system and on different volumes
from those used for your primary objects. You can use the use the MXGNAMES utility as
312 NonStop SQL/MX and RDF