Doing Fup Reload Operations With Updaters Running; Exception File Optimization; Switching Disks On Updater Updatevolumes - HP NonStop RDF J-series RVUs Management Manual

Of course, if you are taking online dumps of your backup database, you must also configure
TMF to perform audit dumping either to tape or disk.

Doing FUP RELOAD Operations With Updaters Running

Because the backup database is audited by TMF, you cannot do FUP RELOAD operations on it
unless you have altered the RDF UPDATEROPEN attribute to SHARED. Previously you needed
to stop the updaters before you could alter this attribute, but RDF now allows you to do this
online. It is recommended that you alter the attribute back to PROTECTED or PROTECTED
OPEN when you have finished the FUP RELOAD operations. The following RDFCOM commands
achieve this alteration:
] ALTER RDF UPDATEROPEN SHARED
] ALTER RDF UPDATEROPEN PROTECTED

Exception File Optimization

The RDF exception files reside in the control subvolume on $SYSTEM. The name of each is the
name of the updater's volume on the primary system.
Each updater maintains an exception file in which it identifies every audit record that must be
undone on the backup database during a takeover. Typically records must be undone because
the outcome of the associated transaction is unknown. When protecting auxiliary audit trails,
however, the outcome of a transaction might be known (a COMMIT record is present in the
Master Image Trail), but if audit for the transaction is missing from an auxiliary audit trail then
the transaction must be undone during the Takeover operation.
If you are protecting only MAT volumes, the amount of undo required during a takeover is
usually small. If one or more long-running transactions are active at the time of a takeover,
however, the amount of undo required can increase substantially (depending upon the amount
of audit records generated by those transactions).
If you are protecting auxiliary audit trail volumes, a considerable amount of undo could also be
required if any of the extractor-receiver pairs (master or auxiliary) falls behind the others prior
to the Takeover operations.
If you have configured an RDF network to replicate network transactions, a considerable amount
of undo could also be required if any of the nodes in the network falls behind the others prior
to a takeover.
In any case, if an updater has a large number of audit records to undo during a takeover, the
performance of its undo pass is negatively affected by logging exception records. Therefore, the
manner in which exception files are used is a configurable attribute.
To set this attribute, use the following RDFCOM command:
SET RDF UPDATEREXCEPTION {ON | OFF}
When this attribute is set to ON (the default value), the updater logs an exception record for
every audit record it must undo during a takeover.
When this attribute is set to OFF, the updater logs exception records only for the first and last
audit records that must be undone (the minimum logging necessary to support Triple Contingency
operation).

Switching Disks on Updater UPDATEVOLUMES

The SCF PRIMARY DISK command causes the disk process to switch to the backup CPU. If you
need to perform this switch on an updater's UPDATEVOLUME, you should always issue a STOP
UPDATE command first, then issue the SCF PRIMARY DISK command next, and then issue a
START UPDATE command.
Doing FUP RELOAD Operations With Updaters Running 155