The Impact of Distributed Transactions
If manual recovery becomes necessary, the process is generally the same regardless of whether the archive journal files contain distributed transaction checkpoint records or not.
However, special action may be needed when a ROLLFORWARD operation terminates or a ROLLBACK operation begins at a point in time when a distributed transaction is active and in an InDoubt state. The problem that arises in these situations is that the recovery utility does not know whether to commit the local changes made by the InDoubt transaction or back them out. Since the utility has no way of communicating with a coordinator to determine what action to take, it may be necessary for the DBA to explicitly specify the final outcome for the transaction.
Determining If InDoubt Transactions Exist
All recovery utilities that report transaction information, also report on distributed transactions. For example, the PRINT JOURNAL and FIX ARCHIVE utilities include information about all distributed transactions in their detailed report and list incomplete transactions in their summary report. Incomplete transactions that are in an InDoubt state will be among those listed in the summary report.
Why There are Incomplete InDoubt Transactions
A distributed transaction is in an InDoubt state when the last journal record written for that transaction is a DIND. Normally, a DCOM or a DBAK record follows a DIND, and its presence determines whether a transaction's changes should be committed or back out respectively. The absence of a DCOM or DBAK record may be because:
The first two conditions may indicate that not all required journal records are being processed. The third condition may necessitate an explicit specification of how to complete the transaction.
Note: For more information about the journal records that are written in support of distributed transactions, see "Two-Phase Commit Journaling" in 19.2.4, “Two-Phase Commit Journaling”.
How Utilities Deal with InDoubt Transactions
By default, the recovery utilities leave an InDoubt transaction in its InDoubt state, meaning that its changes are not rolled out. A DBA can override this default behavior by adding an entry to a manual recovery control file to explicitly specify the action to be take for an InDoubt transaction.
When to Manually Complete Transactions
Explicitly overriding the default action should normally not be necessary. In fact, the presence of InDoubt transactions at the end of a ROLLFORWARD or the beginning of a ROLLBACK operation should be researched to determine the reason for their existence and to ensure that the recovery procedure being followed is valid and includes all necessary journal input.
For example, an InDoubt transaction might validly be encountered when recovering a damaged database file. In this case, the transaction should be allowed to remain InDoubt. When the recovered file is subsequently varied active to the central version, the transaction will be completed (backed out or committed) automatically.
The only time that an InDoubt transaction should be explicitly completed is in exceptional situations that prevent resynchronization from completing the transaction automatically, such as:
Even in the first two situations, if the transaction is still active within the participant central version it should be completed using a DCMT VARY DISTRIBUTED TRANSACTION command rather than using a manual recovery control file override.
How to Explicitly Complete InDoubt Transactions
Before taking any action to complete an InDoubt transaction, you must first determine whether its changes should be committed of backed out. This will typically require using facilities provided by the coordinator to determine the final transaction outcome.
Note: See "Distributed Transaction Recovery Considerations" in 21.4, “Distributed Transaction Recovery Considerations” for potential sources of information.
To explicitly complete an InDoubt transaction, an entry must be added to a manual recovery control file. The following utilities will read a manual recovery control file for this purpose:
To complete a transaction, you must specify its DTRID and an action of either COMMIT or BACKOUT.
If an InDoubt transaction is completed by a utility that creates an output archive file (FIX ARCHIVE, EXTRACT JOURNAL and MERGE ARCHIVE), the utility will write additional distributed transaction checkpoint records that complete the transaction in the specified way.
Note: For more information about the format and use of a manual recovery control file, see the above utilities in the CA IDMS Utilities Guide.
|
Copyright © 2014 CA.
All rights reserved.
|
|