TMF Operations and Recovery Guide (G06.24+)

Occasional Operations
HP NonStop TMF Operations and Recovery Guide—522417-002
3-21
Resolving Distributed Transactions
The ABORT TRANSACTION command provides two options to accommodate different
situations.
The AVOIDHANGING Option
Use the AVOIDHANGING option when you want to remove a hung transaction without
compromising data integrity. Use this option, for example, when data integrity is more
important than the availability of a particular set of files.
When you specify AVOIDHANGING, however, the files affected by a transaction that
cannot be undone are marked undo-needed. These files are not available to any
application until they are repaired by volume recovery or file recovery. Applications
receive an error when they attempt to access files marked undo-needed.
The IGNOREDATAERRORS Option
Use the IGNOREDATAERRORS option only in extreme circumstances, when all efforts
to abort a transaction fail, and data availability is more important than data integrity:
this option can lead to loss of data integrity.
Resolving Distributed Transactions
The RESOLVE TRANSACTION command causes a distributed transaction to commit
or abort. Use this command only if communication between nodes will be down for
more than several hours, or if a transaction is locking a critical database file. In such
cases, a distributed transaction can remain in the prepared state, having not received
data from the home node to commit or abort.
A transaction in the prepared state pins audit-trail files on disk (even if the files have
been dumped): this condition can eventually cause the audit trail to reach its begin-
transaction-disable threshold, which prevents new transactions from starting.
Before you issue the RESOLVE TRANSACTION command, view the status of the
transaction by using the STATUS TRANSACTIONS command at both the home and
remote nodes affected. Table 3-1 shows what action you should take at the remote
node, based on the status of the transaction.
Caution. Of these options, only the AVOIDHANGING option is entirely safe to use; the
IGNOREDATAERRORS option can leave your database in an inconsistent state that cannot be
corrected by the TMF recovery process.
Use the IGNOREDATAERRORS option only when all other efforts to abort the transaction
have failed and data availability is more important than data integrity.
Caution. Manipulating the outcome of a transaction can affect the consistency of your
database. Make sure you understand the status of the transaction at both the home and
remote nodes before you take any of the actions described in Table 3-1.