HP NonStop RDF, Руководство по управлению

Страница: 63 / 478

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 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 table or Enscribe file exists on a volume protected
by RDF, then all partitions for that file should be on volumes protected by RDF. The partitions
of a file protected by RDF can reside on separate systems, and all of the systems should be
protected by an RDF network. These are not absolute requirements, but if you lose your primary
system and must takeover on your backup system, you might not have access to the data that is
not protected by RDF.
Database Block Sizes and Cache on the Backup System
The block size of a file or table on your backup system must be identical to the corresponding
size of the file or table on the primary system. Failure to set proper block sizes on your backup
system can lead to unavoidable data corruption and failure. To ensure fastest RDF updater
performance configure as much cache for the block sizes of your database files as possible.
Specifying System Generation Parameters for an RDF Environment
When performing system generation:
• Use the PATHPACKETBYTES modifier to enable the Expand Variable Packetsize feature
so that Expand will send large packets.
• Use the CONGCTRL modifier to enable Expand congestion control.
• Use the AUDITTRAILBUFFER parameter to improve RDF extractor performance (set to the
highest value).
You might also want to enable the multipacket frame feature, depending upon the type of traffic
that will be passed over the Expand path.
For best results, consider using the RDF Professional Service to assist you in defining the Expand
requirements for your RDF environment. Contact your service provider for further details.
Preparing Software and Database Files for RDF Operations 63