3.2 Microsoft Transaction Server Transaction Recovery Overview

Distributed transaction capabilities are required to use Microsoft Transaction Server with Oracle. Microsoft Transaction Server-related Oracle transactions become in-doubt transactions when any of the following fail:

An Oracle MTS Recovery Service resolves in-doubt transactions on the computer that started the failed transaction. An Oracle MTS Recovery Service is automatically installed with Oracle Services For Microsoft Transaction Server. Only one Oracle MTS Recovery Service can be installed for each computer. A scheduled recovery job on each Microsoft Transaction Server-enabled database permits the Oracle MTS Recovery Service to resolve in-doubt transactions.

The Oracle MTS Recovery Service resolves an in-doubt Microsoft Transaction Server transaction in the following order:

The DBMS recovery job detects an in-doubt MTS-related transaction.

The DBMS recovery job extracts the recovery service's endpoint address from the XID of the in-doubt transaction and requests the recovery service for the outcome of the MTS/MS DTC transaction.

The recovery service requests its MS DTC for transaction outcome.

The recovery service reports transaction outcome to the DBMS job process.

Automatic transaction recovery is performed by scheduling a database job. A database job for in-doubt transactions must be scheduled for each database participating in Microsoft Transaction Server transactions.

Transaction recovery is configured by running the oramtsadmin.sql script, which triggers utl_oramts.sql and prvtoramts.plb scripts to create the PL/SQL package utl_oramts. The database view oramts_2pc_pending is also created to show in-doubt transactions related to Microsoft Transaction Server transactions.

The oramtsadmin.sql script:

Creates the Microsoft Transaction Server administrator user account.

Automatically schedules database jobs for transaction recovery every one minute.

When the database job is run, it checks for unresolved global transactions in the database that are related to Microsoft Transaction Server. Information in the transaction identifiers (XIDs) of the in-doubt transactions identifies the computer on which the transaction was started. The Oracle MTS Recovery Service on that computer resolves the transaction.

Schedules post-recovery cleanup every half hour.

Schedule automatic transaction recovery in the database by performing these tasks:

3.3.2.2 utl_oramts.recover_automatic Procedure

This procedure is run by the transaction recovery job. An automatic database job is scheduled for utl_oramts.recover_automatic. When the job is run, it checks for unresolved global transactions in the database that are related to Microsoft Transaction Server. Information in the XIDs of the in-doubt transactions identifies the computer on which the transaction started. The Oracle MTS Recovery Service is contacted and resolves the transactions.

3.3.2.3 utl_oramts.forget_RMs Procedure

Use this procedure to request the transaction manager (MS DTC) to forget resolved transactions. This procedure is run by the post-recovery cleanup job.

3.3.2.4 oramts_2pc_pending View

The view oramts_2pc_pending is created by executing oramtsadmin.sql. oramts_2pc_pending shows in-doubt transactions in the database. This view consists of the following columns:

Formatid This is the formatid of the global transaction in the database.

global_transaction_id This is the transaction identifier of the Oracle global transaction corresponding to the Microsoft Transaction Server transaction. In fact, this is the globally unique identifier (GUID) of the Microsoft Transaction Server transaction.

branch_id This shows the branch identifier of the Oracle transaction. A single Microsoft Transaction Server transaction can have multiple Oracle global transactions. This depends on the number of Microsoft Transaction Server/COM+ components that span the same Microsoft Transaction Server transaction. All these transactions have the small global transaction identifier, but different branch identifiers.

local_tx_id A local Oracle transaction corresponds to each Microsoft Transaction Server transaction. This column shows the identifier corresponding to this local transaction.

state This shows the state of the transaction: pending, heuristically committed, heuristically terminated, and so on.

protocol This is the protocol that the transaction recovery job in the database uses to communicate with the Oracle MTS Recovery Service.

endpoint This is the endpoint of the Windows computer on which the Microsoft Transaction Server transaction originated. For HTTP connections, this translates to a hostname and port number.

3.4Viewing Microsoft Transaction Server In-Doubt Transactions

To view Microsoft Transaction Server–related in-doubt transactions in the database, use SQL*Plus to query the view oramts_2pc_pending:

This displays the computer on which the in-doubt transaction originated.

3.5Modifying Registry Values for Oracle Fail Safe Configurations

In typical configurations, the MS DTC and Oracle MTS Recovery Service run on the same computer. This ensures that the required information for transaction recovery is available to the Oracle-Microsoft Transaction Server integration layer.

In configurations where the Microsoft Transaction Server application is part of a Windows cluster (for example, the application can fail over to another node or host in the cluster), the MS DTC runs as a cluster-wide resource. All cluster nodes use a single instance of the MS DTC running on any cluster node.

If you have an Oracle Fail Safe configuration, make sure the following registry information is replicated on all nodes in the cluster participating in Microsoft Transaction Server transactions:

To modify registry values for Oracle Fail Safe configurations:

Go to the computer on which the MS DTC and Oracle MTS Recovery Service are installed.

Start the registry from the command prompt:

C:\> regedt32

The Registry Editor window appears.

Go to HKEY_LOCAL_MACHINE\Software\Oracle\OracleMTSRecoveryService.

Copy the registry information appearing here to all nodes in the cluster.

Reboot the computer on which you added the key.

Scripting on this page enhances content navigation, but does not change the content in any way.