SQL/MX 2.x Installation and Management Guide (G06.24+, H06.03+)

Planning Database Security and Recovery
HP NonStop SQL/MX Installation and Management Guide523723-004
5-23
Using Backup and Restore 2 to Create Offline RDF
Backup Databases
Using Backup and Restore 2 to Create Offline RDF Backup
Databases
Use Backup and Restore 2 to specify:
An RDF backup catalog name that is different from the primary catalog, using the
TGT CATALOG syntax
The physical location of SQL/MX objects as they are restored, using the
LOCATION option to restore an SQL/MX file to a different location
Using the Target Catalog Option of RESTORE
You should specify a different RDF backup catalog name using the TGT CATALOG
syntax of the RESTORE command.
Using the LOCATION Option
For information about using MXGNAMES to generate a RESTORE LOCATION clause
for use with RDF, see Using Output Files With RESTORE to Create an RDF Backup
Database on page B-3.
Use the LOCATION option to specify all or part of the physical location of SQL/MX
objects as they are restored. You can specify one or more mappings from source-
volume to dest-volume, or source-filename to dest-filename. For example:
LOCATION
( source-to-dest-mapping )
( ( source-to-dest-mapping
[ , source-to-dest-mapping ] … ) )
where source-to-dest-mapping is one of:
source-volume dest-volume, where both names are of the form
[\node.]$volume.
All files on each source-volume are restored to the indicated dest-volume with
new, system-generated subvolume and file names.
Do not use this option to create an RDF backup database. If you omit the node
name, the name of the local node is used.
source-filename dest-filename, where both names are full Guardian file
names of the form [\node.]$volume.subvolume.filename.
Note. It is strongly recommended that, while the target catalog names differ, the RDF backup
schema and table names match the primary ones exactly. RDF actually uses the specified
physical partition locations to map files on the primary node to those on the backup node. As a
result, the RDF backup database could be created with different schema and table names.
This approach is not recommended because it is harder to manage and makes it difficult or
impossible to use ANSI name-based capabilities in the future.