SQL/MX 3.2.1 Management Manual (H06.26+, J06.15+)

Using file recovery with the TIME option can be difficult, however, because this method requires
you to coordinate the recovery of interrelated objects, such as tables and their indexes.
CAUTION: TMF carries no information about the relationships between file labels and catalogs.
If a table is dropped, for example, file recovery cannot restore the catalog entries for the table. If
the file recovery operation starts at a time just before a table was dropped, you might lose
subsequent DDL changes.
For more information, see the TMF Operations and Recovery Guide.
Recovering Files to New Locations
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.
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.
CAUTION: Do not attempt to recover SQL/MX schemas to a new location, because this action
creates unusable SQL/MX objects.
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. If you attempt to recover without
Recovering Files 237