RDF System Management Manual for H-Series RVUs (RDF 1.8)

and index files, for example). For each audited data file that resides on the primary protected
volume, a corresponding audited file must exist on a volume configured for an updater process
on the backup system. The volume name on the backup can differ from that on the primary. For
example, if volume $B on the backup system corresponds to volume $A on the primary system,
then all files protected by RDF on volume $A must be present (and in the same subvolumes) on
$B.
Chapter 3 (page 73) explains how to copy NonStop SQL/MP databases and Enscribe files to the
backup system after stopping both the TMF product and the applications that use that product
on the primary system. That is the time to copy any files the applications need to the backup
system so that the files are identical on both systems before RDF starts running.
Chapter 16 (page 295) explains how to copy NonStop SQL/MX databases to the backup system
after stopping both the TMF product and the applications that use that product on the primary
system.
Taking Online Dumps of Backup Database.
You should take online dumps on the backup system. Before doing so, you must change the
UPDATEROPEN parameter from Protected (the default value) to Shared. When you are done
dumping, you should then change the UPDATEROPEN parameter back to Protected.
Reload of Backup Database.
If you need to reload the backup database, you must change the UPDATEROPEN parameter
from Protected (the default value) to Shared. When you are done with the reload, you should
then change the UPDATEROPEN parameter back to Protected.
DSM Catalogs and File Code 900
All files that have the file code 900 are replicated by the RDF product. These consist of DSM Tape
Catalog files as well as some related files. In the case of files having the file code 900, RDF
replication of them to the RDF backup system can provide critical information if you later lose
the primary system to a disaster. However, if you also have a DSM Tape Catalog and related
files that specifically pertain to the backup system, you must be careful to place the replicated
files in a different location on the backup system. For example, suppose you have a DSM Tape
Catalog and related files on $CAT.DSMCAT on the primary system, and you have a different
DSM Tape Catalog and related files on $CAT.DSMCAT on the backup system that specifically
pertain to the backup system. In that case you must replicate the DSM Tape Catalog and related
files on the primary system to a different location than $CAT.DSMCAT on the backup system.
For example, you might want to replicate $CAT.DSMCAT.* on the primary system to
$DATA.DSMCAT.* on the backup system. In that way replication of the DSM Tape Catalog and
related files from the primary to the backup system does not affect the DSM Tape Catalog and
related files in $CAT.DSMCAT.* on the backup system.
Views on the Backup System
If an application uses any NonStop SQL/MP or NonStop SQL/MX shorthand or protection views
on a volume protected by RDF, audit data for transactions on the views refers only to the
underlying tables and not to the views. Views and their underlying base tables must be present
on the backup system after a takeover operation so that applications can continue without
interruption.
All base tables underlying the views must also reside on volumes protected by RDF on the
primary system.
Partitioned Tables and Files
If any partition of a partitioned NonStop SQL/MP or NonStop SQL/MX table or Enscribe file
exists on a volume protected by RDF, then all partitions for that file should be on volumes
68 Preparing the RDF Environment