Online Database Synchronization With Nonstop Sql/Mx Objects; Creating The Fuzzy Copy On The Primary System - HP NonStop RDF J-series RVUs Management Manual

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
Location"
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

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
a NonStop SQL/MX Backup Database From an Existing Primary Database" (page
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 326), 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
328 NonStop SQL/MX and RDF
for general restore syntax for NonStop SQL/MX databases.
Chapter 7.
"Restoring to a Specific
"Creating
326), but