SQL/MX 3.2 Management Manual (H06.25+, J06.14+)

Table Of Contents
to obtain a copy of your source objects. Transactions can be active against the source objects at
the time of the recovery.
CAUTION: If you use the MAP NAMES option of the RECOVER FILES command to recover files
to a new location, you must immediately make new online dumps of the target data files recovered.
Without these new dumps, you will not have file-recovery protection for those files, and subsequent
file recovery operations can fail. In particular, if you later try to use old online dumps of the target
files to recover the target files to a point beyond the time that the last RECOVER FILES command
was issued, the file recovery process fails during the redo phase and transmits EMS message 175:
Encountered a File Hiatus record for audit file filename at
audit trail Index #index, SNO #sno, RBA #rba.
Recovering Metadata
TMF is the primary means of recovering metadata associated with catalogs, but other methods
exist.
You can use the TMF file recovery method to recover metadata associated with catalogs to a point
where they were consistent. If any tables of the catalog have the undo-needed or redo-needed flag
set, you should recover all the tables in the definition schema for that catalog by following the TMF
recovery procedures for this method. See “Recovering Files (page 233) and “Recovering Files With
the TIME Option” (page 233).
CAUTION: Do not recover individual tables in a catalog. To keep an SQL/MX catalog consistent,
you must recover all the tables in the catalog as a set.
If you have backup tapes available, you might be able to re-create catalogs by restoring its tables
using the BRCOM RESTORE command. See “Restoring Catalogs” (page 248).
If the TMF and RESTORE recovery methods fail or are not available, you might be able to correct
the inconsistencies by using a licensed MXCI process to change metadata information.
Inconsistencies can arise from the incorrect use of SCF commands or the incorrect use of licensed
programs.
Recovering Database Objects
NOTE: Even though TMF supports recovery to different volumes and different systems, SQL/MX
database objects cannot be recovered to different disk volumes or to systems that have different
node names and numbers. To completely recover systems that contain SQL/MX database objects,
the backup and recovery system must have the same disk volume name, node name, and node
number as the primary system.
Recovering Range Partitions
This subsection pertains to range-partitioned tables only. Hash-partitioned tables automatically
redistribute data when they are dropped. Therefore, there is no need to recover a hash partition
that is accidentally dropped. Adding the partition will automatically redistribute the data into the
new hash partition.
A range partition must be empty to be dropped. However, you can recover a dropped partition
to a time when it was not empty by first specifying the original physical file name of the partition
and then re-adding it:
MODIFY TABLE CAT.SCH.T056T11
ADD PARTITION.....LOCATION \NSK.$DATA6.ZSDADLON.ONL42Q00
Next, recover the entire table and subordinate objects by using the complete set of Guardian file
names as indicated to ensure that all partitions are recovered to the same state.
236 Performing Recovery Operations