Takeover Operations; The Rdf Takeover Operation; Phase One Undo Pass - HP NonStop RDF J-series RVUs Management Manual

When the extractor for RDF subsystem #1 reports an RTD time of 0:00, then you know that
extractor has caught up and you can then prepare for another switchover operation to move
your application processing back to \A, as follows:
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.
NOTE: There are variety of variations you can do to achieve the above operations. The method
provided above is just one means to achieve this.

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 on 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. 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
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.
Chapter 17 for details.
Takeover Operations 139