Oracle TRC Files and MTS
Version 2.4
April 07, 1999
Under some circumstances your Oracle database may produce .TRC files when used with Microsoft Transaction Server. This document describes what TRC files are, why they are produced, and what you can do to eliminate them.
TRC files are produced by
your Oracle database. The online Oracle documentation describes the Oracle
trace facility as follows:
“The trace facility allows a network or database administrator to obtain more information on the internal operations of the components of an Oracle application network than is provided in a log file. Tracing an operation produces a detailed sequence of statements that describe the events as they are executed. All trace output is directed to trace output files that can be evaluated to identify the events that led to an error.”
Your Oracle database software produces .TRC files. These files are designed to provide more information about errors that are detected and reported by Oracle database software. Several Oracle components are capable of producing TRC file. For the remainder of this document we will focus on the TRC files produced by Oracle’s XA facility.
No, Microsoft software never produces .TRC files.
The Oracle XA trace facility is described in the online “Oracle8 Documentation Library” that accompanies the Oracle8 product. To locate this documentation, do the following:
1. In the “Oracle8 Documentation Library” select “Oracle8”
2. Go to the “General Oracle8 Enterprise Edition” heading in the table of contents and select “Application Developer’s Guide”.
3. Go to “Chapter 18 Oracle XA” in the table of contents and select “Troubleshooting” and then “Trace Files”.
A typical Oracle XA TRC file contains information like that shown below.
093452.280:309.309.1:
ORACLE XA: Version 7.3.4.0.0. RM name = 'Oracle_XA'.
093452.280:309.309.1:
xaolgn: XAER_RMERR; upiahs failed. ORA-12154.
093452.280:309.309.1:
ORA-12154: TNS: The name of the Service was not resolved
A TRC file is produced when MS DTC attempts to perform an XA operation with your Oracle database and the Oracle XA operation reports an error. The TRC files are the means by which Oracle reports additional error information. Some XA errors result from normal XA database operations such as trying to commit or rollback a transaction. Other XA errors may result when MS DTC attempts to perform XA recovery with your Oracle database.
Understanding how XA Recovery works may help you better understand how XA recovery may result in TRC files.
Whenever MTS opens an Oracle database connection under XA transaction control, MS DTC writes a log record to the dtcxatm.log file. These log records are used to keep track of each active Oracle database connection. The log record also contains the open string used to open the Oracle database connection. The MS DTC transaction manager uses this open string to reconnect to the Oracle database if XA recovery is necessary. Whenever MTS successfully closes an Oracle database connection, the corresponding log record along with its open string is deleted from the dtcxatm.log file.
If an Oracle database, an MTS host application process, or the MS DTC transaction manager process fails while an Oracle database connection is open, MS DTC must perform database recovery. If the Oracle database fails while MS DTC remains active, MS DTC will immediately attempt to reconnect to the Oracle database and perform recovery. If the MS DTC transaction manager process fails, MS DTC will attempt to reconnect to the Oracle database and perform XA recovery as soon as MS DTC is restarted.
MS DTC performs recovery by reading the dtcxatm.log file to determine which Oracle database connections, if any, need recovery. It retrieves the open string for the Oracle database connection and opens the database. MS DTC then sends an XA_RECOVER request to the Oracle database. In response to the XA_RECOVER request, the Oracle database sends MS DTC a list of the transactions that were active or in-doubt at the time of the failure. MS DTC tells Oracle whether each active or in-doubt transaction committed or aborted. Recovery completes when the Oracle database has been told the outcome of all active or in-doubt transaction. When recovery completes, MS DTC deletes the log record for that Oracle connection from its dtcxatm.log file.
If MS DTC cannot recover the Oracle database connection, either because MS DTC cannot open the Oracle database or because of some other recovery-related error, MS DTC will delay for one minute and then retry recovery. MS DTC will continue retrying recovery once each minute until recovery is successful. MS DTC is persistent in retrying recovery because the Oracle database is required to hold record locks for all active or in-doubt transactions until recovery is complete.
The Oracle database may produce a .TRC file on each unsuccessful recovery attempt. If recovery fails repeatedly, many Oracle TRC files may be produced.
If you delete the MS DTC dtcxatm.log file, you are deleting all information concerning unrecovered Oracle database connection. This prevents MS DTC from attempting to perform Oracle database recovery. When MS DTC stops trying to recover your database you may no longer get TRC files. The problem with deleting the log file is that it may leave your Oracle database in an inconsistent unrecovered state.
If you are getting unwanted Oracle Trace files, do the following.
1. Ensure that Oracle XA Transaction Support is Enabled
One of the most common reasons for getting trace files is that Oracle has not been properly configured to support XA recovery. In this case, every attempt to perform Oracle XA recovery may fail. This can result in hundred or thousands of Oracle TRC files like the following:
121454.240:244.244.1:
ORACLE XA: Version 7.3.4.0.0. RM name = 'Oracle_XA'.
121454.240:244.244.1:
xaofetch: XAER_RMERR; upipse rtn ORA-942; sql_stmt=SELECT k2gtifmt,
k2gtitid_ext, k2gtibid FROM sys.v$xatrans$
121454.240:244.244.1:
ORA-00942: table or view does not exist
You can correct this problem by enabling Oracle XA transaction support as described in the “Oracle and MTS” document. You can obtain this document from ftp.microsoft.com/bussys/viper/docs
2 Ensure that Oracle.is Not Tracing XA_RDONLY Return Values
Make certain that you are running at least version 7.3.3.5 of Oracle. The Oracle 7.3.3.5 Readme entry for bug 460407 reports that on earlier Oracle releases, the Oracle xa_prepare call logged an error when it received a return code of XA_RDONLY. This is actually a legal return code for an Oracle xa_prepare call. Oracle should only have logged this message if extended tracing was requested (dbgfl > 0).
Here is an example of the TRC file produced when XA_RDONLY calls are erroneously logged.
122242.420:72.72.6:
ORACLE XA: Version 7.3.3.0.0. RM name =
‘Oracle_XA’.
122242.420:72.72.6:
xaoprepare: xaoswitchprep rtn 3.
3 Install MS DTC Hot Fix 809.
Install MS DTC hot fix 0809. This hot fix corrects a problem in the MS DTC transaction manager. MS DTC sometimes failed to properly delete XA database recovery information from the dtcxatm.log file. The dtcxatm.log file should typically be less than one megabyte in size. Under some circumstances the log file could grow to hundreds of megabytes.
You may obtain MS DTC hot fix 0809 from ftp://ftp.microsoft.com/bussys/distapps/MTS/Public-Fixes/usa/DTC/SvcPack/.
4 Ensure that Your Oracle Name Server is Configured Properly.
At least one customer has seen the following TRC information when their Oracle Name Server was not configured properly.
092813.283:222.222.13687:
ORACLE XA: Version 7.3.4.0.0.
RM name = 'Oracle_XA'.
092813.283:222.222.13687:
xaolgn: XAER_RMERR; upiahs
failed. ORA-12154.
092814.283:222.222.13687:
ORA-12154: TNS:could not
resolve service name
This customer was having trouble when using the Oracle Name Server. They were able to circumvent the problem by making an entry in their local TNSNAMES.ORA file. Our testing showed that recovery worked properly when using either TNS or the Oracle Name Server. Unfortunately we were never able to determine why the customer had a problem when using Oracle Name Server.
You can control the location of the TRC files if you have installed the Windows NT4 Service Pack 4 release. Do this as follows:
1. Ensure that the mtxoci.dll installed on your MTS system is version 1998.08.762.0 or later. Version 1998.08.762.0 was released with the NT4 Service Pack 4 release. It was the first version of the mtxoci.dll that allows you to control the location of Oracle trace files.
2. Use the Explorer to find and delete any existing Oracle trace files on your system. These files have names ending with the suffix “.TRC”. By deleting any obsolete trace files, you make it easier to find any newly created ones.
3.
Run REGEDIT to create the following
registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Transaction
Server\Local Computer\My Computer\OracleTraceFilePath
Give this key the following REG_SZ value:
C:\OraTrace
You may choose a different disk drive and directory for the trace files if you
wish.
4. Use the Explorer to create the Oracle trace file directory. In our example, create the directory “OraTrace” on the “C” drive.
5. Stop the MTS package that is accessing the Oracle database. By stopping the package you ensure that all existing Oracle database connections are closed and that new Oracle database connections will be opened when the MTS component is next invoked. These newly opened Oracle database connections will use the new trace directory location.