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

The Audit-Fixup Process
The audit-fixup process only ever runs on the remote standby system in an RDF/ZLT environment
and typically lasts only a few seconds. The audit-fixup process performs file-fixup operations on
audit trail files on the remote mirror that have been left with the CRASHOPEN flag set following a
failure of the RDF primary node. The audit-fixup process is started by an extractor whenever the
extractor attempts to read an audit trail file that has the CRASHOPEN flag set. Unlike the other
RDF processes, the audit-fixup process does not persist for the duration of the RDF environment.
The audit-fixup process is started on demand by the extractor process, and terminates as soon as
it has performed the file-fixup processing on the audit trail file.
This process does not run as process pair, but the extractor will start a new audit-fixup process if
the audit-fixup process is terminated due to a processor failure. No configuration parameters are
required for the audit-fixup process. The audit-fixup process runs in the same CPU as the extractor
primary process with a process priority one less than the extractor priority.
Phase 2 (Takeover Processing)
The initial part of Phase 2 takeover processing is performed by the purger in building the undo
lists. When an updater reaches the end-of-file of its image trail, it asks the purger for an undo list.
(The purger cannot start building the undo lists until all receivers have finished their ZLT processing.)
The updaters use those lists to back out any audit for transactions that were unresolved on the
primary system at the time of the unplanned outage.
ZLT Events
Event Management System (EMS) events are logged to report the progress of the ZLT operation in
the various RDF processes. For descriptions of these messages, see messages 900 through 903 in
Appendix C (page 346).
Error Conditions
If the standby system is different from the backup system and the monitor cannot reach the standby
system to start the extractor(s), the takeover operation aborts. If that happens, you must bring the
standby system up (and make sure it is available to the backup system by way of the Expand
network) and then reissue the TAKEOVER command.
If an extractor cannot find an audit file it needs because the disk has not yet been mounted, the
extractor abends and the takeover operation aborts. If you have not yet mounted the disk the
extractor needs, you must mount it before reissuing the TAKEOVER command. If the remote mirror
cannot be mounted and you want to do the takeover without the ZLT guarantee, you can alter the
RDF REMOTE MIRROR attribute on the backup system to off. When you reissue the TAKEOVER
command, the takeover then proceeds as a normal takeover operation (without ZLT).
STATUS RDF
You cannot issue the STATUS RDF command from the standby system; it must only be issued from
the backup system.
If a takeover does not involve ZLT, the extractor is not included in the STATUS display during an
RDF takeover operation. With ZLT configured and enabled, the STATUS RDF display changes
during an RDF takeover. During phase 1 (ZLT processing), status is displayed for the extractor(s),
consisting of process name, sno, rba, cpus, error. The RTD field, however, is left blank.
RDFCOM INFO and SHOW Commands
The INFO command output includes the RDF and extractor configuration attributes for ZLT, as does
the output for the SHOW command.
326 Zero Lost Transactions (ZLT)