RDF System Management Manual for H-Series RVUs (RDF 1.8)

3. Restart the updaters (issue a START UPDATE command on the primary system).
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 primary system volume.
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 there is no way of knowing for certain that all the associated audit
records were successfully replicated to the auxiliary image trail prior to the takeover.
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 a takeover.
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, the SCF PRIMARY DISK command next, and then a START UPDATE
command.
NOTE: If you enter the SCF PRIMARY DISK for an updater's UPDATEVOLUME, the affected
updater might report a number of RDF 700 events with the file-system errors 10, 11, and 71. If
these errors occur, they will be reported immediately following the disk primary event. In this
situation, these errors can be expected and they do not indicate that the backup database has
become inconsistent with the primary database. To avoid these errors, always stop the updaters
first, issue the SCF PRIMARY DISK command, and restart the updaters.
Online Remirroring of Updater SUBVOLUMES
If you attempt to re-mirror an updater's UPDATEVOLUME online, the affected updater might
report a number of RDF 700 events with the file-system errors 10, 11, and 71. In this situation,
these errors can be expected and they do not indicate that the backup database has become
Exception File Optimization 145