RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

• Copies of NonStop SQL views on the backup systems
• Placement of partitioned Enscribe files and NonStop SQL tables
Audited Files Per Volume on Primary System
The RDF updater process has a limit on the number of database files it can have open concurrently
on a volume - 3,000. Therefore, when you set up your database on your primary system for RDF
protection, you should ensure that you do not have more than 3,000 audited files on any single
volume that you want replicated. If you have more, then you should consider moving some of these
to a different volume. If you fail to do this, in some situations it can cause the updater to slow down
in performance. For more information, see Chapter 5 (page 113).
Audited Backup Database Files
The backup system must have copies of all files that RDF protects. For a successful takeover of
business operations in the event of a primary system failure, the backup system should also have
copies of all the files needed by the primary system applications (including alternate key files 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 62) 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 307) 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.
Reload of Backup Database.
If you need to reload the backup database, you must change the RDF UPDATEROPEN parameter
from Protected (the default value) to Shared. When you are done with the reload, you should then
change the RDF UPDATEROPEN parameter back to Protected. Previously you needed to stop the
updaters before modifying this attribute, but you can now modify it online, without stopping the
updaters. For more information see, “SET RDF” (page 217)command in Chapter 8 (page 176).
Disk Process Pins on Database Volumes
To ensure the fastest updater performance, you should configure as many disk process pins as
possible for the volumes on which your backup database resides. This is a particularly important
requirement if your primary system has really high audit generation rates and you want the RDF
updaters to keep up with that audit generation rate.
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,
Preparing Software and Database Files for RDF Operations 57