Preparing Databases For Rdf Protection; Audited Files Per Volume On Primary System; Audited Backup Database Files; Reload Of Backup Database - HP NonStop RDF J-series RVUs Management Manual

backup database, you must also take audit dumps too. For more information see,
command in

Preparing Databases for RDF Protection

When preparing databases on the primary system for RDF protection, you must consider the
following system aspects:
• Maximum Number of Audited Files Per Volume on Primary System
• Copies of files for the backup database
• DSM catalog and file code 900 replication
• 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

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 69)
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 323)
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,

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.
62 Preparing the RDF Environment
Chapter 8 (page 187).
explains how to copy NonStop SQL/MP databases and Enscribe files to the
explains how to copy NonStop SQL/MX databases to the backup system
Chapter 5 (page
"SET RDF"command in
"SET RDF"
121).
Chapter 8 (page 187).