RDF System Management Manual for H-Series and J-Series RVUs (RDF 1.9)

If the takeover completes on the backup system, the purger logs an RDF event 888 specifying a
MAT position (sno, rba). Subsequently, when the primary system is once again online and you
are ready to switch the applications back to the primary, you first initiate a TMF file recovery
command on the former primary system, using the TOMATPOSITION option with the MAT
position from the 888 event. TMF restores the primary database to the exact same state that the
backup database was in when the takeover operation completed.
NOTE: You always use the logged MAT position from the 888 event message to initiate the file
recovery operation, even if the RDF configuration is replicating auxiliary audit trails.
You then configure the RDF subsystem to run from the backup to the primary system to bring
the primary database back up to date with updates that took place while the primary was down.
When the primary database is fully current, you can then perform a planned switchover from
the backup to the primary system, and restart your applications on the primary system.
If the purger issues an 858 event message, file recovery on the primary system is not possible.
This is only possible during a Takeover operation that involves an RDF network. See the discussion
in Chapter 14 on how this situation can happen.
Online Method of Resynchronizing the Primary Database
When an RDF takeover operation completes, the purger process logs the RDF event 888, which
specifies a Master Audit Trail position. On your primary system, you can then execute TMF File
Recovery with the TOMATPOSITION option. This option requires a MAT position, and you use
the position in the RDF Event 888. When File Recovery completes, the database on your primary
system is in complete logical synchronization with the database on your backup system at the
time when the RDF takeover operation completed. If you had resumed business operations on
your backup system, run a new RDF configuration to bring the old primary system up to date
with the business operations that have taken place on the old backup system. When RDF has
brought the former primary up to date, you can then perform a switchover operation to move
business operations to the former primary.
If you have an RDF Network, there are some situations where File Recovery with the
TOMATPOSITION option is not possible. If that is the case, RDF logs an RDF Event 858 at the
end of the takeover operation.
Offline Method of Resynchronizing the Primary Database
After a takeover and when the failed primary system is restored to operable condition, you can
take the following steps to restore the original RDF configuration and make the old primary
database the current primary database again (where \A is the old primary system and \B is the
old backup system):
1. Stop the applications and TMF on \B.
2. Save the database on \B to tape or use NonStop AutoSync to put a copy of your backup
database on your primary system.
3. Restart the applications and TMF on \B.
4. Initialize RDF on \B to the shutdown timestamp generated in Step 1.
5. Configure RDF to go from \B to \A.
6. Start RDF (\B to \A) with update off.
7. Restore the database on \A.
8. Turn on updating.
9. When RDF has caught up, do a planned switchover from \B to \A (as described earlier).
If you have an RDF Network, there are some situations where File Recovery with the
TOMATPOSITION option is not possible. If that is the case, RDF logs an RDF Event 858 at the
end of the takeover operation.
148 Critical Operations, Special Situations, and Error Conditions