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

and UNDONEEDED flags. For views, tables, indexes, and ENSCRIBE files, the information
appears after the modification timestamp of the table.
Normally, volume recovery recovers such files when the volume is started for transaction
processing. If, however, the volume is already started and the file is still marked with
REDONEEDED or UNDONEEDED, you must recover the file by using file recovery.
Recovering Files
File recovery is usually the method to use if other recovery methods fail. Use file recovery only if
you consistently dump audit trails to tape and make online dumps. File recovery reconstructs an
audited file from the initial starting point of the online dumps and applies all the changes to the
file from the history of the audit trails. The file is recovered to the last consistent point in the database.
These guidelines apply:
• Invoke the file recovery process by issuing the RECOVER FILES command to a TMF interface
such as TMFCOM. The process prompts the operator for the online dumps and audit-trail tapes
as needed. Audit trails that still reside on disk are read directly from disk.
• If you do not specify the FROMARCHIVE option in the RECOVER FILES command, file recovery
recovers only files marked undo-needed. If you specify the FROMARCHIVE option of the
RECOVER FILES command, file recovery attempts to recover the entire file set, regardless of
the setting of the redo-needed and undo-needed flags.
• The file recovery process cannot recover a file that did not exist at the time of an online dump.
The process cannot perform a create function. You must perform an online dump following a
create operation. If you do not do so, you cannot recover the file because TMF looks for a
starting point on the latest online dump.
• A REDONEEDED or UNDONEEDED flag in the FILEINFO display for a file, after a volume
has been enabled for TMF processing, indicates that you must use file recovery to recover the
file.
• To recover SQL/MX tables, use TMF file sets consisting of the Guardian names of the underlying
files making up the tables and related indexes, in the RECOVER FILES command. To convert
the ANSI names of the tables to their underlying Guardian file names, run the MXGNAMES
utility as described in “Using Guardian Names with TMF, RDF, and Measure” (page 309) and
the SQL/MX Reference Manual.
Recovering Files With the TIME Option
By using the file recovery feature with the TIME option, you can resolve several types of problems:
• If a database object is dropped by accident, you can use the TIME option to recover the
object's file as it existed just prior to the drop. This action effectively recovers the entire file
but not the catalog definition of the object.
• If an application error updates the database in an inconsistent way, you can recover the
database to the state it was in at a specified time before the error occurred.
• If a licensed MXCI or mxtool GOAWAY operation incorrectly alters or damages the database
or catalogs, you can recover the database or catalogs to their previous state.
• If you have a saved test database or starting database, you can recover that database to the
same point many times. Suppose that in your testing procedures you need to always start with
the same database. This database can be loaded to the node or recovered by using TMF file
recovery with the TIME option.
236 Performing Recovery Operations