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

Performing Recovery Operations
HP NonStop SQL/MX Installation and Management Guide—544536-007
12-4
Recovering Files to New Locations
Recovering Files to New Locations
You can recover data from SQL/MX files to populate 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
Caution. If you are using SQL/MP aliases, you might need to update your alias definitions
after you recover an SQL/MP file to a new location. For more information, see the SQL/MX
Reference Manual.
Note. NonStop SQL/MX does not allow you to recover SQL/MX files to new locations by
specifying different node names, volumes, subvolumes, or file IDs (for example, to recover
from a hardware failure). Instead, you must recover to the exact same location as the original
file. The Guardian file location for each SQL/MX object partition is stored in its resource fork
and file label, and neither TMF or the user can alter this information.
Caution. Do not attempt to recover SQL/MX schemas to a new location, because this action
creates unusable SQL/MX objects.