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

rates for RDF-protected data on a given audit trail are generally in the range of 1 to 3 megabytes
of audit per second, the number of updaters you need does not exceed 30, and you normally run
with Update ON, you may be able to configure one image trail per updater and place that
imagetrail on that updater's UPDATEVOLUME. You should have sufficient disk space to hold both
your database files as well as the image trail. When determining if you have sufficient disk space
on the UPDATEVOLUME, you should consider size of individual image trail files and the configured
value of the purger's RETAINCOUNT, and you should consider worst-case situations where an
updater might fall way behind, in which case there might be a large number of image files on that
UPDATEVOLUME.
Alternatively, you may find that you can configure a small number of dedicated image trails and
configure a large number of updaters to each dedicated trail provided that the volume of audit
being written to the trail is generally less than 5 megabytes per second. For high volume throughput
where the volume of RDF-protected data in an audit trail exceeds 5 megabytes per second, for
optimal extractor-to-receiver throughput as well as for optimal updater throughput, it is recommended
that you always use dedicated image trails and that you configure no more than 3 or 4 updaters
per image trail.
As you can see from this discussion, there are many combinations one can achieve, depending
on the volume of audit being generated per datavol on the primary system and the number of
updaters you configure to an image trail. The recommendations provided above are no more than
general recommendations. Each customer's environment differs. When you are ready to configure
your image trails, you need to consider carefully the different considerations raised above.
Setting Trigger Attributes
RDF offers two types of triggers, where a trigger is typically a user-generated script of operations
that are automatically executed upon the completion of a specific event. The two types of triggers
are the REVERSE trigger and the TAKEOVER trigger. The REVERSE trigger is executed by RDF only
for a STOP RDF, REVERSE operation, and it is executed immediately after RDF stops. The TAKEOVER
trigger is executed immediately upon the successful completion of an RDF takeover operation.
Use SET TRIGGER and ADD TRIGGER commands to configure the following trigger attributes:
• PROGRAM
• INFILE
• OUTFILE
• CPUS
• PRIORITY
• WAIT or NOWAIT
The PROGRAM parameter specifies the name of a Guardian object file that is executed once RDF
has reached a particular state, either after a STOP RDF, REVERSE, or TAKEOVER operation.
The INFILE attribute specifies the name of an edit file that will be passed as the IN file to the trigger
process when it is created.
The OUTFILE attribute specifies the name of a file or process that will be passed as the OUT file
to the trigger process when it is created.
The CPUS attribute specifies the number of the primary and alternate CPUs in which the trigger
process is to run.
The PRIORITY attribute specifies the priority at which the trigger process will run.
WAIT causes RDF to wait for the trigger process to terminate before shutting down. NOWAIT
specifies that once the trigger process is launched, RDF can immediately proceed to shut down.
For further details on how you might use these triggers, see the sections on switchover and takeover
in Chapter 6 (page 148).
82 Installing and Configuring RDF