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

When the RDF subsystem #1 extractor starts sending current audit information to \A (and at a
convenient time with respect to your processing environment), stop Applications #1 and carry
out a planned switchover from \B to \A:
1. On system \B, create an audited Enscribe file on each data volume in the RDF subsystem
#1 configuration.
2. Wait until all of those files are created on system \A.
3. On system \B, stop RDF subsystem #1.
4. Purge the Enscribe files on both systems.
5. On system \A, initialize RDF subsystem #1 using the INITTIME option and specifying the
current (for \A) local time.
6. On system \A, restart Applications #1.
Takeover Operations
If the primary system fails and you want to switch application processing to the backup system,
you need to issue the TAKEOVER command from the backup system. The TAKEOVER command
causes RDF to shut down after bringing the backup database to a consistent state.
The RDF Takeover Operation
When updating is enabled, updaters apply audit as soon as it is safe-stored in the image trails
on the backup system. In this respect, they apply audit without waiting to determine if the
associated transactions committed or aborted. At the moment when you lose your primary system
due to some unplanned outage, the updaters might have applied audit for transactions whose
outcomes were not resolved (committed or aborted) on the primary system at the time the primary
system failed. Alternatively, the transactions might have been resolved on the primary system,
but the extractor 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. For takeover considerations in a ZLT environment,
see Chapter 17 (page 309).
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.
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 the Volume
Recovery would have undone on the primary system if it had been able to.
Takeover Operations 135