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

name but the Guardian filename will not normally be the same, even if the partitions are
on different volumes.
7. Create each object on the backup system.
The ANSI name of the object must be constructed as follows:
catalog name: use the name of the backup catalog you created in Step 2.
schema name: use the name you used in Steps 4 and 5.
table or index name: must match on the primary and backup systems.
This command creates a table called TAB1 in the schema BCAT.SCH, with three partitions,
located on volumes $data02, $data13, $data14, respectively.
CREATE TABLE BCAT.SCH.TAB1 (a int not null, b int, primary key (a))
LOCATION $DATA02.ZSDXYZ3A.KQY8KY00
PARTITION
(ADD FIRST KEY (100) LOCATION $DATA13.ZSDXYZ3A.KQY8RK00,
ADD FIRST KEY (200) LOCATION $DATA14.ZSDXYZ3A.KQY8YG00);
The subvolume.filenames are identical between the primary and backup systems in
this example, but two of the volumes have been remapped for RDF between the primary
and backup systems: $data02 is replicated to $data02, but $data03 is replicated to
$data13 and $data04 is replicated to $data14.
With regard to the Guardian filename, you must use a fully-qualified LOCATION clause,
thereby ensuring that the underlying Guardian subvolume.filenames are identical
on the primary and backup systems; otherwise, the updater will report a 736 event, listing
the underlying Guardian subvolume.filename of the object, and the updater will
wait until you have created such a file.
The above rule applies to the SG_TABLE associated with the IDENTITY column as well.
At this point, you will have to correct the naming problem as described in “Correcting
Incorrect NonStop SQL/MX Name Mapping” (page 316).
When you have completed Steps 6 and 7 for each table and index, the primary database
is ready for transaction activity, and the backup database is ready for RDF to replicate
that transaction activity.
Creating a NonStop SQL/MX Backup Database From an Existing Primary
Database
To create an RDF backup NonStop SQL/MX database from an existing primary database, perform
these steps:
1. Create a catalog on your backup system to correspond to the primary system catalog whose
objects you want RDF to replicate. The name of the backup catalog must differ from the name
of the primary catalog. The volume in the optional LOCATION clause might differ from the
volume used on the primary system.
CREATE CATALOG catalog_name LOCATION optional_guardian_location;
For example, if issued on the backup system, the command
CREATE CATALOG BCAT LOCATION $DATA01;
creates a catalog named BCAT on volume $DATA01 on the backup system.
For the rest of this procedure assume that the name of the primary system is \PNODE and the
name of the backup system is \BNODE.
2. Create the schema on the backup system using the same schema name and the same subvolume
name as on the primary system.
For example, if issued on the backup system, this command creates a schema on the backup
system called SCH in catalog BCAT using subvolume ZSDXYZ3A:
310 NonStop SQL/MX and RDF