The Audit-Fixup Process; Phase 2 (Takeover Processing); Zlt Events; Error Conditions - HP NonStop RDF J-series RVUs Management Manual

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
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

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.
365).
"The Audit-Fixup Process"
ZLT Takeover Operations
below),
343