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

NOTE: Before issuing the TAKEOVER command, you must have connected the remote mirrors to
the standby system. When the remote mirrors are connected to the standby system, the audit records
on the remote mirrors have no relationship to the audit trail on the standby system. The remote
mirrors are not part of the TMF configuration of the standby system.
Phase 1 (ZLT Processing)
RDFCOM stops all RDF processes on the backup system. If the standby and backup systems are
not the same system, RDFCOM copies the RDF configuration file on the backup system to the
standby system. RDFCOM then starts an RDF monitor process on the backup system. That monitor
then starts the extractor(s) on the standby system and the receiver(s), purger, and updater(s) on the
backup system.
Each extractor logs RDF event 901 reporting it is started for ZLT processing, starts a special
audit-fixup process to fix up the last file in the audit trail (see “The Audit-Fixup Process” below),
and sends all remaining audit records to its receiver. When an extractor reaches the end of its
audit trail, it sends a “ZLT finished” indication to its receiver, and logs RDF event 900 reporting it
has completed its ZLT task. When all extractors are finished, they are terminated and deleted.
Upon receiving the “ZLT finished” indication, each receiver logs RDF event 903 reporting it has
completed its ZLT task, and tells its updater to commence normal takeover operations. When all
receivers have finished their ZLT processing, the overall takeover operation proceeds to phase 2.
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 356).
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.
ZLT Takeover Operations 335