TMF Operations and Recovery Guide (G06.24+)

Recovery Methods
HP NonStop TMF Operations and Recovery Guide—522417-002
7-29
Recovering From a Complete System Failure
If TMF is unable to communicate with a parent node, TMF startup waits. If you cannot
restore the required communication path or cannot wait for this to occur, you may have
to manually resolve the pending distributed transactions. Refer to Controlling
Individual Transactions on page 3-20 for information on resolving transactions.
Restarting TMF in a Heterogeneous Distributed Transaction
Environment
When TMF is restarted in a heterogeneous distributed transaction environment, it first
attempts to resolve any pending heterogeneous transactions. When possible, it
communicates with the foreign transaction managers through resource manager
gateway processes to determine the outcome of such transactions. (When
heterogeneous transactions are pending, the gateway processes must be restarted.)
During the start operation, the resource manager gateway processes may open the
resource managers. In response to the open operation, all in-doubt transactions
pertaining to these resource managers will be sent to the gateway processes. During
the remainder of the start operation, all of these in-doubt transactions will be
completed. TMF does not finish the start operation, and new transactions are not
allowed to begin, until the outcome of all in-doubt transactions is determined.
If TMF is unable to communicate with a foreign transaction manager and there are
imported transaction branches in the in-doubt state, TMF startup will wait until the
transactions are complete. If you cannot restore the required communication path or
cannot wait for this to occur, you may have to resolve the pending imported
transactions manually. Notice that if there are exported transaction branches in the in-
doubt state, TMF startup is not affected. Nonetheless, these exported transaction
branches must be completed to clean up data structures for the transaction. For
information about resolving transactions, refer to Controlling Individual Transactions on
page 3-20.
Recovering From a Complete System Failure
In case of a complete system failure caused by a major power outage or natural
disaster, the NonStop Remote Database Facility (RDF) product provides fast recovery
of the production database—in minutes—for critical OLTP applications. The NonStop
RDF subsystem monitors database updates by TMF on the primary system and
applies those updates to a copy of the database on a remote backup system.
If you experience a complete system loss and are not using the NonStop RDF
subsystem, you should contact the Global Support Center (GCSC) or your service
provider before attempting to recover your database and TMF system.
Resolving Distributed Transactions After Recovering a
Database
You need to resolve any distributed transactions that existed when the parent system
failed. In a homogeneous distributed transaction environment, how you do this