DSM/Tape Catalog User's Guide

Database Design of DSM/TC
DSM/Tape Catalog User’s Guide — 520233-008
9 - 2
Restoring Disk Files
Restoring Disk Files
DSM/TC contains enough information to restore a disk file based on the fully qualified
file name and the time it was written to tape. The catalog can be consulted to
determine exactly which tape volume or volumes contain the disk file.
To invoke the RESTORE program to recover a disk file, use the MEDIACOM
RECOVER DISKFILE command. If the CATALOGFILES option of the BACKUP
program was specified for the backup, the RESTORE program starts on the
appropriate volume in the volume set. CATALOGFILES does not apply to Backup
Restore 2.0 BACKUP. Otherwise, the entire volume set is searched.
Updating the DSM/TC Database
Only NonStop Kernel system software updates DSM/TC. Applications that read or write
tape files never modify DSM/TC directly. When an application writes a tape file, the
system combines information from the user's TAPECATALOG DEFINE and the tape
volume's label and enters it in DSM/TC.
The BACKUP utility updates DSM/TC as it copies disk files to tape. Information is
automatically deleted from DSM/TC as tape files become obsolete and expire. Also,
MEDIACOM commands such as DELETE TAPEFILE alter the DSM/TC database.
The Catalog Manager Process
The catalog manager process is the focal point for all updates to the DSM/TC
database, and all database requests are routed through it. Additionally, the catalog
manager maintains the interrelationships and preserves consistency between SQL
tables. TMF transactions are used to coordinate database access, maintain
consistency, and protect the data against system or media failures.
The catalog manager receives requests from MEDIASRV, the BACKUP (T9074) and
BACKCOPY utilities, the $ZSVR process, Backup and Restore 2.0, and MEDDEM.
Each component, or instance of a component, creates its own catalog manager and
sends requests to it. BACKCOPY is a standard Backup Restore utility.
For example, if multiple users simultaneously run BACKUP, each BACKUP process
creates its own catalog manager. The catalog manager assumes the user ID of the
process making the request. As a result, it ensures the appropriate security to access
the DSM/TC database. A catalog manager process remains until the parent process
terminates or no requests are received for a specified timeout value. Requests are sent
to the catalog manager using file-system procedures.
Typically there is only one catalog manager process for each instance of a system
component. However, because the DSM/TC database can be distributed across
multiple nodes, the catalog manager is divided into one catalog manager process per
system. Each remote catalog manager handles database requests locally, and
maintains database consistency and the logical relationships between database tables.