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

Performing Recovery Operations
HP NonStop SQL/MX Installation and Management Guide—523723-004
12-4
Recovering Files to New Locations
Recovering Files to New Locations
If necessary, you can recover files to new locations by specifying different systems,
volumes, subvolumes, or file IDs (for example, to recover from a hardware failure).
You can also recover files to create new SQL/MX objects that are different from the
originals. You can create the new objects in different catalogs and schemas by using
different locations. However, the new objects must have the same file attributes,
security settings, partitioning scheme, and indexing scheme as the originals. When
recovering these files, you must map the dumped files to the corresponding Guardian
files associated with the target table object.
TMF does not apply SQL/MX file-label modification records encountered in an audit
trail for an object being recovered to a new location. Therefore, the file label in the
online dump must match the file label of the newly created target, and the target’s file
label must match the final form of the source file label. To recover to a new location,
you must take new online dumps each time the file label is modified. Resource forks in
NonStop SQL/MX are the equivalent of file labels in NonStop SQL/MP. For this reason,
do not include resource forks in the RECOVER FILES command when you recover
SQL/MX objects to a new location.
The TMFCOM RECOVER FILES command accepts only Guardian file names in its
input. Therefore, when you want to recover SQL/MX objects to a new location, you
must specify the underlying Guardian file names for these objects. You can simplify the
recovery by using the method illustrated in the next paragraph.
If two SQL/MX objects are in different schemas, they are assigned to different
subvolumes. However, you can make the file ID portion of the target object identical to
the file ID of the source object. For example, if you want to recover the SQL/MX table
HRDATA.PERSNL.EMPLOYEE (with the Guardian file name
$DATA10.ZSDT5356.NG59FJ00) to another SQL/MX table named
HRDATA.DUPPERSNL.EMPLOYEE, and ZSDT3122 is the subvolume for the schema
DUPPERSNL, you can specify that the table HRDATA.DUPPERSNL.EMPLOYEE be
created in the location $DATA12.ZSDT3122.NG59FJ00. You can also do the same for
the dependent objects of HRDATA.PERSNL.EMPLOYEE. If all the dependent objects
are located on $DATA10 for the source and $DATA12 for the target, you can use the
RECOVER FILES command to recover these objects:
RECOVER FILES $DATA10.ZSDT5356.*, NOT $DATA10.ZSDT5356.*1, &
MAP NAMES ($DATA10.ZSDT5356.* TO DATA12.ZSDT3122.*)
SQL/MX objects being recovered to a new location must be created before the
recovery process is run, and the target objects must exactly match the source objects.
Caution. If you are using SQL/MP aliases, you might need to update your alias definitions
after you recover a SQL/MP file to a new location. For more information, see the SQL/MX
Reference Manual.
Caution. Do not attempt to recover SQL/MX schemas to a new location, because this action
creates unusable SQL/MX objects.