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

was stopped before it could send the final outcomes to the backup system. The takeover operation
determines what audit needs to be backed out in order to bring the backup database into a stable
and consistent state. Audit is backed out of the backup database during three possible undo passes,
described below. With proper configuration of the RDF/ZLT product, no transactions that were
committed on the primary system are ever lost due to an unplanned outage that requires an RDF
takeover operation. There are special considerations that pertain to the Takeover command in a
ZLT environment. See Chapter 17 for details.
With the RDF/IMPX product, it is possible that some transactions that committed on the primary
system might be lost due to an unplanned outage. How many committed transactions are lost
depends entirely on whether the extractor was keeping up at the time of the outage or whether the
extractor had fallen behind for some reason.
When the takeover operation completes, your backup database is in a consistent and stable state
with regard to transactions that committed on your primary system.
Phase One Undo Pass
This is also known as Local Undo. Audit can be backed out of the backup database for two possible
reasons.
• If an updater has applied audit for a transaction whose outcome is unknown, that audit must
be backed out.
• If RDF is replicating audit from aux audit trails and if the final outcome is known, but not all
of the audit for the transaction from an aux trail reached the backup system, that audit must
be backed out.
Transactions that must be undone during this undo pass are stored in the ZTXUNDO file in your
Master Image Trail subvolume. You can use the READLIST utility to see what transactions were
undone by this Local Undo operation.
Phase Two Undo Pass
This is also known as File Undo. If one or more volumes failed on the primary system and a
transaction aborted, the TMF Backout process will backout the transaction on the volumes that are
still up, but it will be unable to backout the audit on the volumes that are down. If the downed
volumes come back online, the TMF Volume Recovery process backs out the audit that the Backout
process could not back out. If, however, the primary system failed before Volume Recovery had
enabled the downed volumes, then, if you execute the RDF Takeover operation on the backup
system, the updaters execute an undo pass that will undo the audit that Volume Recovery would
have undone on the primary system if it had been able to.
Transactions that must be undone during this undo pass are stored in the ZFILUNDO file in the
Master Image Trail subvolume. You can use the READLIST utility to see what transactions were
undone by this File Undo operation.
Phase Three Undo Pass
This is also known as Network Undo. If you are running in an RDF network and you lose one or
more primary systems, you must do a takeover on all backup systems in your RDF network. For a
complete description of the takeover operation in an RDF network, see “RDF Takeovers Within a
Network Environment” (page 282).
Transactions that must be undone during this undo pass are stored in the ZNETUNDO file in the
Master Image Trail subvolume.
Issuing the TAKEOVER Command
Before you issue a TAKEOVER command on your backup system, you need to start an RDFCOM
session for the correct control subvolume. For example, if you were running RDF from \Boston to
Takeover Operations 131