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

Restoring the Primary System
After you initiate a takeover, it is possible that the last committed transactions on the primary system
did not make it to the backup system (meaning that the backup and primary databases are not
synchronized). When the failed primary system is restored to operable condition you have two
methods of resynchronizing your primary database with your backup database where your
applications are now running. One method is online, and the other is offline.
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.
Takeover Operations 139