MSDTC error in Event Viewer

[drkestrel]

I am using Ms DTC on Windows 2000 Professional workstation with SP2 with Microsoft .NET.

I get the following error whenever I start up Component Services. The Data Access Layer component I have installed under DTC uses Oracle OLE provider (on a Oracle 9i server), but at the time of starting up the MSDTC, no objects were instantiated and no transactions are active (as confirmed by lookin at Distributed Transaction Coordinator-> Transaction list, Transaction Statistics). What is this error and how could I stop it?
The error occurs in the Application branch of event viewer 3 to 4 times
every second!!
The error:

The XA Transaction Manager attempted to perform recovery with the XA resource manager. The XA resource manager reported that recovery was unsuccessful. DSN = MTxOCI.Dll.


I have the following under my registry, which is required to get my Data Access Component working:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI]
"OracleXaLib"="oraclient9.dll"
"OracleSqlLib"="orasql9.dll"
"OracleOciLib"="oci.dll"

 

[sfriday]

I too get this very same error, have you found a fix as yet.
I have searched the WEB but no joy!!

Steve
Regards
Steve Friday

 

[sfriday]

I have found this document and although it mentions 8i maybe it wil assist you in your solution.

http://support.microsoft.com/support/complus/mtsandoracle.asp?SD=GN&LN=en-gb&gssnb=1

There is a section on Enable Oracle XA transaction support, I am not an oracle person but we are investigating this at present as a possible cause.
Regards
Steve Friday

 

[sfriday]

More info for you, search your server for .trc files, these are Oracle trace files that get left behind when a recover fails, an example of mine is shown below


ORACLE XA: Version 9.0.1.0.0. RM name = 'Oracle_XA'.


184131.504:616.616.48:
ORA-00942: table or view does not exist



184131.504:616.616.48:
xaorecover: xaofetch rtn -3.


Regards
Steve Friday

 

[sfriday]

Another usefull link

http://support.microsoft.com/default.aspx?scid=KB;EN-US;q246006&

Regards
Steve Friday

 

[sfriday]

More info, the following was located by one of our DBA's as a fix

Doc ID: Note:33293.1
Subject: Common Issues When Configuring Oracle XA on UNIX
Type: BULLETIN
Status: PUBLISHED
Content Type: TEXT/PLAIN
Creation Date: 26-JUN-1998
Last Revision Date: 09-JUL-2002


Purpose
=======

This article offers general advice for users who wish to configure Oracle
XA on Unix systems.


Scope and Application
=====================

If this is the first time of using XA interface, customers may find minor
problems when compiling programs and linking. Below is helpful information to
resolve these problems.

Contents
________

A. Linking and Precompiling XA
B. Required Information for Support
C. Common problems


A. Linking and Precompiling XA
_______________________________


1) The Oracle Server xa_switch_t structure name is xaosw.
The resource manager name within xa_switch_t is Oracle_XA.

N.B. In Oracle 8 and above, dynamic registration is supported, if the
TP Monitor supports this. To use this you must use the structure
xaoswd.

2) The libraries required to link oracle with a Transaction Monitor are all
contained in the client shared library libclntsh and followed by whatever
is referenced in $ORACLE_HOME/lib/sysliblist

The line will end something like this:

-lclntsh .... -lm -lc

On Oracle 8 & 9 there are two object files for static or dynamic registration:

xaonsl.o - For static registration
xaondy.o - For dynamic registration

These are in the $ORACLE_HOME/rdbms/lib directory.

3) On version 7 the precompiler must have the flag 'release_cursor=yes' set
to close all explicit cursors before committing a transaction.


B. Required Information for Support
___________________________________


Before and/or when raising a TAR with Support, consider the following details.


1) The type of Transaction Monitor being used, common examples are Tuxedo, CICS,
TopEnd, MQSeries, etc.

2) Version of Oracle, XA and the Transaction Monitor.

3) The XA open string. This will start with Oracle_XA and have fields joined
by plus signs +Acc and +SesTm are required, the rest are optional, for
example:

Oracle_XA+Acc=P/<user>/<password>+SesTm=60+SqlNet=<alias>+MaxCur=150

SQL*Net is optional, but must be configured if anything other than the default
database is used. See [NOTE:1005968.6] about XA and database links.

Note: in the Tuxedo configuration file, the format of the open string is as
follows:

OPENINFO=&quot;Oracle_XA:Oracle_XA+Acc=P/<user>/<password>+ ... &quot;

For further details see [NOTE:704555.101]

4) Error number(s), if and when an error occurs. Also, check for a stack trace,
if a core dump file is created when the error appears.

5) If it is not clear why the XA error is occuring, add the following to the
open string. Send the XA log to Oracle Support.

+LogDir=<some log directory>+DbgFl=15

This prints out all the XA calls that are being processed.


C. Common problems
__________________


1* Distributed database option is not installed. The solution is to install the
option.

2) a) In Oracle 8 and later all XA users must have select privilege on
SYS.DBA_PENDING_TRANSACTIONS.

b* XA views have not been installed. As the SYS user run &quot;xaview.sql&quot;,
or on some later systems &quot;catxa.sql&quot;.

Grant select to everyone who will use the Transaction Monitor on
V$XATRANS$.

Check with SQL*Plus to see if the user named in the open string can
select from this table.

3) Ensure that Pro or OCI are not doing any of the following:

a) Connecting to the database. EXEC SQL CONNECT or orlon.

b) Committing or rolling back transactions.

The above commands must run via the relevant Transaction Monitor calls. They
have various names for different monitors, some of which are implicit. The
calls will have names similar to tx_open, tx_commit, tx_rollback, tx_close.

c) SAVEPOINT savepoint.

d) SET TRANSACTION READ ONLY.

These are both illegal when using XA.

e) Any DDL statements e.g. CREATE TABLE

These have an implicit COMMIT and therefore cannot be used with XA.

f* ORA-1001 Invalid Cursor - They have not compiled with release_cursor=yes.

g) Various Oracle errors may occur if a SQL statement is executed and a
transaction has not been begun. All SQL statements must be in a
transaction i.e. follow a tx_begin, even if they do not change the
database. In Oracle 8 this is allowed but it must use dynamic
registration, see note above on the switch structure name.

h) ORA-23 and Ora-22. These may occur if a database link is being used, see
[BUG:230566] and [BUG:233574] for further information.

To use a database link with XA you must close the database link before
ending or migrating the session. If this is not possible, as it is not
on some Transaction Monitors, the multi-threaded server must be used
for the connections.

* Only relevant for Oracle version 7.

Oracle Documentation
====================
Oracle 9i References

Oracle9i Application Developer's Guide - Fundamentals (Chapter 20)
Oracle9i JDBC Developer's Guide and Reference (Chapter 15)


Oracle 8i References

Oracle 8i Application Developer's Guide - Fundamentals (Appendix A)
Oracle 8i Pro*C/C++ Precompiler Programmer's Guide (Chapter 5-54)
Oracle 8i Application Developer's Guide (Chapter 8-54)


Oracle 8.0 References

Oracle Application Developers Guide (Chapter 18)
Oracle Pro*COBOL Precompiler Guide (Chapter 4-37)
Oracle Pro*C/C++ Precompiler Guide (Chapter 4-55)
Oracle8 Server Migration Guide (Chapter 6-2)
Oracle8 Parallel Server (Chapter 8-11, A-7)


Oracle 7.3 References:

7.3 - Oracle7 Server Distributed Systems,
Volume I: Distributed Data (Chapter 7)

Further References
==================

[NOTE:1005968.6] V7.X.X: ORACLE SERVER AND UNIX TRANSACTION PROCESSING
[BUG:230566] ORA-23 OCCURS DURING XAEND WHEN USING DATABASE LINKS AND WORKING
WITH PRO*
[BUG:233574] XA CAN NOT BE USED WITH DBLINK



Regards
Steve Friday

 

[BillLumbergh]

We have this problem as well. We cannot figure out what is causing it, but we have been able to get it to go away. Here is what we do:

Go into component services. Right click on My Computer. Select Properties -> MSDTC tab, then click &quot;Stop&quot;. Now, open a command prompt, and go into c:\winnt\system32\dtclog. You can also do this through windows explorer; however, I've found that when I go that way, my machine grinds away for quite some time before listing the directory contents, so DOS is faster and easier in my opinion. Now, you want to delete the file MSDTC.log. If you're not comfortable doing this, rename it or something. I think the command is &quot;del msdtc.log&quot;, not to tell you something you don't know, but DOS is not my forte, and if someone told me to delete a file in DOS, I might not know how to do it without specific commands.

Then, go back into the MSDTC properties window you left open earlier. Click the &quot;Reset Log&quot; button. After this, just so you know, if you go back into the directory we went to above, there will be a new MSDTC.log file in there, and it will be in our case 4,096 KB. This may vary depending on some setting on your machine.

Now, still on the MSDTC properties window, click &quot;Start&quot;.

This should get rid of the MSDTC warnings.

I welcome any suggestions or elaborations on this problem. I feel like the fix we use is a shady one as we are not addressing the actual cause of the problem but reacting to its symptoms, and to be honest, I don't really know why our steps work or if they cause some other problems.

I don't know if this happens for your, but when we start seeing this warning, our application starts opening Oracle connections and not releasing them. So the Oracle guys don't like this because it ties up their application for other users. So our fix fixes this problem, stops the warnings, and releases the Oracle connections but beyond that I don't know.

I've seen some documentation suggesting that simply stopping, resetting, and starting the MSDTC will solve the problem; however, that didn't work for us, it was like the reset was leaving old data transaction data in there that caused it to still fail, so that's why we started to actually delete the msdtc.log file. We've seen no ill side effects from doing this but again there may be problems that aren't readily apparent.

sfriday: so if I find those .trc files, what do I do with them?

Let me know if this helps.

 

[sfriday]

Open the trc files, they will tell you what the problem is or it did for us, we did not have public access to a DBA_Pending table, applied the correct access and problem went away.

Steve Regards
Steve Friday