In Doubt transactions
In Oracle, how do you find out if there are any in doubt transactions
In DB2, its
DB2>LIST INDOUBT TRANSACTIONS
How would you do this in Oracle ?
desc dba_2pc_pending
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/ds_txnman003.htm
SELECT local_tran_id, global_tran_id, state, mixed, advice, tran_comment FROM dba_2pc_pending;
Similar Messages
-
Question on Lock in In-Doubt Transaction
Dear All,
Could you kindly explain me why distributed transaction imposes a lock on read also with write? During Read, Select statement also uses rollback segment.
But in the document Oracle9i - Database Administrators Guide Release 2 (9.2) - March 2002 Part No. A96521-01 at page 31-16, it has been written that
the data is locked for both reads and writes. Oracle blocks reads because it cannot determine which version of the data to display for a query.
So could we come to a conclusion that distributed transaction does not use rollback segment.
But at page 31-18, under manual resolution of In-Doubt Transaction, the first point is that the in-doubt transaction has locks on critical data or rollback segment.
Therefore, rollback segment is using during distributed transaction. So why does Oracle impose a lock on READ the data?
Regards,
StudentRedo logs are effectively write-only under normal circumstances. The database NEVER goes back to read the redo log unless it is in crash recovery mode.
Therefore, even though the information has been recorded in the online redo log, that information can not be used to roll back a failed in-doubt transaction. The rollback information MUST come from the rollback segment or from some other online location.
(I am not taking this as an argument - it's helping me as well.) -
Weblogic leaves in-doubt transaction on Oracle when it fails
Hi,
I'm looking at resilience with our Weblogic (6.1sp2) and Oracle
(8.1.7) environment, and have been doing a few tests. We're using the
Oracle OCI (thick) driver, in "XA" mode (i.e. using the "Driver"
oracle.jdbc.xa.client.OracleXADataSource). We need to do this because
our application uses JMS/Message driven beans to intiate a lot of the
work, and any database activity that fails needs to be rolled back
together with the message and any other work. We don't "enable
two-phase commit" as shown on the TxDatasource config, so get real XA
behaviour, with JMS and the JDBC connection as the XA resources.
The problem is when/if Weblogic dies. As WLS is the transation
manager, if a transaction is in-flight at the time WLS fails the XA
resources need to take action. If the TM fails after the transaction
starts but before the prepare() calls, it seems as though things
generally work out; Oracle rolls back its transactions, and when WLS
is restarted, the JMS messages are recovered and re-delivered (after
the initial delay period of five minutes). The problem seems to be
when WLS dies between the prepare and the commit. In this case, Oracle
holds the various locks it needs to commit the transaction, and when
WLS is restarted it doesn't seem to inform the XA resources that the
transaction should be rolled back/abandoned. Until a DBA sorts out the
problem, any attempts to use the locked areas (e.g. anything that does
a table scan or uses specific rows) result in errors of the form:
ORA-01591: lock held by in-doubt distributed transaction 18.65.2221
This is sensible as far as Oracle's concerned - it doesn't know if any
other XA resources committed or rolled back their transactions.
However, I'd have expected WLS, as the TM, to have sent the necessary
instructions to Oracle once the transaction has been recovered.
Nothing in WL's logs implies it's trying to do anything with recovered
transactions.
I've managed to make this repeatable. I have a class which I can send
a JMS message to kill the server. This MDB calls
Runtime.getRuntime.halt(1) (to simulate a serious crash) either during
the transaction (in onMessage()) or registers its own "XA killer"
resource which calls halt(1) in the prepare(). In the latter case I
always get an in-doubt transaction.
Anyone else had this behaviour, and more importantly, know how to
resolve it?
JamesLou,
any information about the results of testing of the patch from oracle for 'in-doubt
transaction' problem?
Thanks
Sanjay
"Fei Luo" <[email protected]> wrote:
>
James,
Our support engineer is still testing the patch from Oracle. I
will keep you updated on this.
[email protected] (James Elson) wrote:
"Fei Luo" <[email protected]> wrote in message news:<3cee9c1c$[email protected]>...
Are you using Oracle817? Yes, we are.
There is a known Oracle817 bug that may be related to
your problem. You may try Oracle901.Ah. Such an upgrade would have major implications on our architecture.
Do you have any more information on this bug (a bug number etc)?
Would we have to upgrade the server, or just the clients?
James -
How to create an in-doubt transaction?
I need to create/force an MSDTC in-doubt distributed transaction to verify that they are resolved automatically. The code successfully participates in the transaction via OraMTSSvcGet and OraMTSSvcEnlist and works as expected. I have tried creating in-doubt transactions via constraint violations, table locking, killing the application, killing the Oracle session, etc. but can't force an error between the first and second phase of the commit( which I think is the trick). Any ideas?
Message was edited by:
jgbellIf your site is dynamically populated with content from server-side databases, it's not hard.
If your site is static, a 3rd party search function might be a better choice until you're ready to build a dynamic site.
Zoom search engine
http://www.wrensoft.com/zoom/
Freefind
http://www.freefind.com/
Setting up a PHP environment in Dreamweaver
http://www.adobe.com/devnet/dreamweaver/articles/setup_php.html
Building your first dynamic website – Part 1: Setting up your site and database connection
http://www.adobe.com/devnet/dreamweaver/articles/first_dynamic_site_pt1.html
Nancy O.
Alt-Web Design & Publishing
Web | Graphics | Print | Media Specialists
http://alt-web.com/
http://twitter.com/altweb -
Unable to rollback in-doubt transactions
We are using Oracle 10g R2 on Linux platform. When I execute the below rollback statement, it executes successfully but the state of the transaction remains same i.e. prepared. Due to this, when we try to update some row in the table, "ORA-01591 lock held by in-doubt distributed transaction..." is thrown by sqlplus.
ROLLBACK FORCE '10.10.36244821';
Followings are the contents of DBA_2PC_PENDING
LOCAL_TRAN_ID
GLOBAL_TRAN_ID
STATE
MIXED
FAIL_TIME
RETRY_TIME
OS_USER
OS_TERMINAL
HOST
COMMIT#
10.10.36244821
1463898948.00000143D0D116E10000000C00003B1F001F318F7CB4CAB62B82A96CF3CE98C592462030
prepared
no
01/27/2014 00:12:28
01/28/2014 12:01:48
was
unknown
rzyz.lj.et
11201668706058
Followings are the contents of DBA_2PC_NEIGHBORS
LOCAL_TRAN_ID
IN_OUT
DATABASE
DBUSER_OWNER
INTERFACE
DBID
SESS#
BRANCH
10.10.36244821
in
jdbc_699
xyz
N
jdbc_ttc_impl
4.0000
00000143D0D116E10000000C00003B1F001F318F7CB4CAB62B82A96CF3CE98C592462030000000010000000000000000000000000005
10.10.36244821
in
jdbc_713
xyz
N
jdbc_ttc_impl
3.0000
00000143D0D116E10000000C00003B1F001F318F7CB4CAB62B82A96CF3CE98C592462030000000010000000000000000000000000004
10.10.36244821
in
jdbc_700
xyz
N
jdbc_ttc_impl
2.0000
00000143D0D116E10000000C00003B1F001F318F7CB4CAB62B82A96CF3CE98C592462030000000010000000000000000000000000003
10.10.36244821
in
jdbc_702
xyz
N
jdbc_ttc_impl
1.0000
00000143D0D116E10000000C00003B1F001F318F7CB4CAB62B82A96CF3CE98C592462030000000010000000000000000000000000002
We are using a JEE appliction (EJB) on IBM WebSphere that is generating ORA-01591 error in the log file when it runs the update statement against a table.See http://support.oracle.com:
note 126069.1 "Manually Resolving In-Doubt Transactions"
note 100664.1 - Master Note for Oracle managed distributed transactions -
ORA-01591 Lock held by in doubt transaction
We have this error
ORA-01591 Lock held by in doubt transaction
this error appear randomly when
in the same transaction we use inser,delete or update sentence and a call to MS-MSMQ ( asynchronous transaction)
(Oracle 9i 9.2.0.5, HP Itanium Unix)
(Web application with .NET ODP Provider)
thanks for your helpHi Vivek,
This error is encountered by many DBA's and cause problem by locking the distributed transaction process, and not letting the query go through, because the Two - Phase Commit Mechanism got an error somewhere.
he DBA should query the pending_trans$ and related tables, and attempt to repair network connection(s) to coordinator and commit point.
Here are some codes to help you through the process:
This one brings in-doubt transactions:
select * from DBA_2PC_PENDING where state='prepared'
This one prepares the rollback script for the transactions:
select 'rollback force '''||local_tran_id||''';' from DBA_2PC_PENDING where state='prepared'
All this is well described in below link
ORA-01591: lock held by in-doubt distributed transaction
ORA-01591: lock held by in-doubt distributed transaction string tips
On BizTalk Side you need to make ambient transaction to false as Oracle does not go ahead with DTC Transaction with Biz Talk
Thanks
Abhishek -
关于in-doubt transaction清理，管理员手册说到：
The RECO background process of an Oracle Database instance automatically resolves failures involving distributed transactions. At exponentially growing time intervals, the RECO background process of a node attempts to recover the local portion of an in-doubt distributed transaction.
那么这个exponentially growing time intervals如何算法，RECO到底等多久才会出来“大扫除”呢？
如果，没有发生1591之类的报错，是不是可以不必理会，死等RECO出来干活儿呢？
昨天遭遇了in-doubt transaction事件，由于某个DB达到最大会话数引起，在恢复正常后，至少两个小时内，pending事物还没有被自动清理，后来手工rollback force处理的。
并且观察到，在手工干预之后又过了几十分钟，dba_2pc_pending中的rollback force记录确实被自动清理掉了，
故有此问SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for 64-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
SQL> set linesize 200
SQL> set pagesize 1400
SQL> SELECT x.ksppinm NAME,y.ksppstvl VALUE, x.ksppdesc describ
2 FROM SYS.x$ksppi x, SYS.x$ksppcv y
3 WHERE x.inst_id = USERENV ('Instance')
4 AND y.inst_id = USERENV ('Instance')
5 AND x.indx = y.indx
6 AND x.ksppinm like '%distributed%';
NAME VALUE DESCRIB
distributed_lock_timeout 60 number of seconds a distributed transaction waits for a lock
_distributed_recovery_connection_hold_time 200 number of seconds RECO holds outbound connections open
distributedrecovery_connection_hold_time 隐藏参数默认为200s， 控制了Oracle会允许一个失败的事务连接持续打开， 该参数最大可以设置为4,294,967,295s， 但是RECO进程仍会每30分钟会唤醒一次并处理失败的分布式事务。 默认值200一般是建议的， 不需要额外修改。
注意分布式事务 会让数据库不稳定， 分布式事务是方便的 ，但是分布式事务是罪恶的(evils)
*<font color="red" size="2" face="courier">如果觉得本回复有意义，请点击本条回复右手边的Correct按钮，谢谢！</font>*
如何在OTN中文技术论坛提一个问题？
论坛礼仪需知及学习oracle的方法论
Maclean Liu
Oracle Database Administrator
Oracle Certified 10g/11g Master
www.askmaclean.com -
"in-doubt distributed transaction" (WLS 8.1 SP2/Oracle 9.2.0.4)
I've developed an MDB that reads a message from a queue, performs database updates
against up to 2 databases, and sends an outgoing JMS message when all is complete.
The MDB uses container-managed transactions to ensure that all DB updates and
JMS messages are committed or rolled back together. I have had a lot of problems
related to transactions failing, becoming "in-doubt" in the database and locking
database resources indefinitely.
My environment is configured as follows:
WebLogic 8.1.2 Server
Oracle 9.2.0.4 database with RAC
XA Connection Pool with WebLogic Type 2 Oracle Driver OR Oracle 9.2.0.4
OCI Driver
I have read the BEA/HP white paper regarding Weblogic 8.1 with Oracle 9i RAC (http://dev2dev.bea.com/products/wlserver81/whitepapers/wls_bea_hp.jsp)
and have tried all of the solutions suggested in that paper. The only solution
that worked consistently without causing the in-doubt transactions was to change
my connection pools to point directly to a single node of the RAC cluster, not
to the shared instance. However, even with this configuration, I have seen these
errors occur when certain database failures occur.
A side-effect of this problem is that the associated WebLogic connection pools
begin to "forget" connections. The pool thinks that all of the connections are
in use (even though I am always calling Statement.close() and Connection.close()),
and the connection pool cannot be reset manually. The only way to clear the connection
pool is to bounce WebLogic.
The only posts I have found related to this error were regarding Oracle 8.1.7
and WebLogic 6.1. Any help would be greatly appreciated.
Exceptions:
<Mar 23, 2004 2:59:36 PM EST> <Error> <EJB> <BEA-010026> <Exception occurred during
commit of transaction Xid=BEA1-0526A28664707F28EDB9(6412513),Status=Rolled back.
[Reason=javax.transaction.xa.XAException
: prepare failed for XAResource 'ProfilingPool' with error XAER_NOTA : The XID
is not valid],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=2,seconds
left=60,XAServerResourceInfo[JMS_my
JmsStore]=(ServerResourceInfo[JMS_myJmsStore]=(state=rolledback,assigned=myserver),xar=JMS_myJmsStore),XAServerResourceInfo[ProfilingPool]=(ServerResourceInfo[ProfilingPool]=(state=rolledback,ass
igned=myserver),xar=ProfilingPool),SCInfo[mydomain+myserver]=(state=rolledback),local
properties=({}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+10.41.0.61:7001+m
ydomain+t3+, XAResources={JMS_myJmsStore, JMS_FileStore, ProfilingPool, SearchManagementPool,
AnnouncementsTxPool},NonXAResources={})],CoordinatorURL=myserver+10.41.0.61:7001+mydomain+t3+):
javax.tran
saction.xa.XAException: prepare failed for XAResource 'ProfilingPool' with error
XAER_NOTA : The XID is not valid
at weblogic.jdbc.oci.xa.XA.createException(XA.java:386)
at weblogic.jdbc.oci.xa.XADataSource.internalPrepare(XADataSource.java:905)
at weblogic.jdbc.oci.xa.XADataSource.prepare(XADataSource.java:885)
at weblogic.jdbc.jta.DataSource.prepare(DataSource.java:846)
at weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:1167)
at weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:401)
at weblogic.transaction.internal.ServerSCInfo$1.execute(ServerSCInfo.java:253)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
--------------- nested within: ------------------
weblogic.transaction.RollbackException: Could not prepare resource 'ProfilingPool
prepare failed for XAResource 'ProfilingPool' with error XAER_NOTA : The XID is
not valid - with nested exception:
[javax.transaction.xa.XAException: prepare failed for XAResource 'ProfilingPool'
with error XAER_NOTA : The XID is not valid]
at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1644)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:300)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:221)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:412)
at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
2004-03-23 15:00:45,406 ERROR IS003989 [ExecuteThread: '17' for queue: 'ProfileCompleteListenerBean.ExecuteQueue']
my.package.search.business.ProfiledHoldingDAO.setProfilingStatus(ProfiledHoldingDAO.java:350
) - Failed to update profiling status for holding 10014 [] (-2)
java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for
lock
at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:282)
at weblogic.jdbc.oci.PreparedStatement.executeUpdate(PreparedStatement.java:226)
at weblogic.jdbc.oci.xa.PreparedStatement.executeUpdate(PreparedStatement.java:81)
at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:94)
at my.package.search.business.ProfiledHoldingDAO.setProfilingStatus(ProfiledHoldingDAO.java:345)
at my.package.search.business.ProfilingManager.disseminateAndAcknowledge(ProfilingManager.java:254)
at my.package.search.business.ProfileCompleteListenerBean.onMessage(ProfileCompleteListenerBean.java:128)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:382)
at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
2004-03-23 15:01:43,093 ERROR IS003989 [ExecuteThread: '18' for queue: 'HoldingStatusListenerBean.ExecuteQueue']
my.package.search.business.ProfiledHoldingDAO.getProfilingStatus(ProfiledHoldingDAO.java:265)
- Failed to retrieve profiling results for holding 10060 [] (-2)
java.sql.SQLException: ORA-01591: lock held by in-doubt distributed transaction
189.47.12
at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:282)
at weblogic.jdbc.oci.PreparedStatement.executeQuery(PreparedStatement.java:152)
at weblogic.jdbc.oci.xa.PreparedStatement.executeQuery(PreparedStatement.java:48)
at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:80)
at my.package.search.business.ProfiledHoldingDAO.getProfilingStatus(ProfiledHoldingDAO.java:256)
at my.package.search.business.ProfiledHoldingDAO.storeHoldingMetadata(ProfiledHoldingDAO.java:489)
at my.package.search.business.ProfiledHoldingDAO.storeNewHolding(ProfiledHoldingDAO.java:406)
at my.package.search.business.ProfilingManager.profileHolding(ProfilingManager.java:128)
at my.package.search.business.HoldingStatusListenerBean.onMessage(HoldingStatusListenerBean.java:121)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:382)
at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
Hi. There is a serious bug in the Oracle DBMS (all versions) where in-doubt
transactions have their data locked in the DBMS by page rather than by row,
so it will indefinitely prevent access to all data on the page, including
logically uninvolved data. Oracle understands the problem but currently
says they will never fix it (it would take too much work). They offer the
alternative that you configure your table data to ensure that no more than
one datarow resides on a page.
Joe
Matt Smith wrote:
> I've developed an MDB that reads a message from a queue, performs database updates
> against up to 2 databases, and sends an outgoing JMS message when all is complete.
> The MDB uses container-managed transactions to ensure that all DB updates and
> JMS messages are committed or rolled back together. I have had a lot of problems
> related to transactions failing, becoming "in-doubt" in the database and locking
> database resources indefinitely.
>
> My environment is configured as follows:
> WebLogic 8.1.2 Server
> Oracle 9.2.0.4 database with RAC
> XA Connection Pool with WebLogic Type 2 Oracle Driver OR Oracle 9.2.0.4
> OCI Driver
>
> I have read the BEA/HP white paper regarding Weblogic 8.1 with Oracle 9i RAC (http://dev2dev.bea.com/products/wlserver81/whitepapers/wls_bea_hp.jsp)
> and have tried all of the solutions suggested in that paper. The only solution
> that worked consistently without causing the in-doubt transactions was to change
> my connection pools to point directly to a single node of the RAC cluster, not
> to the shared instance. However, even with this configuration, I have seen these
> errors occur when certain database failures occur.
>
> A side-effect of this problem is that the associated WebLogic connection pools
> begin to "forget" connections. The pool thinks that all of the connections are
> in use (even though I am always calling Statement.close() and Connection.close()),
> and the connection pool cannot be reset manually. The only way to clear the connection
> pool is to bounce WebLogic.
>
> The only posts I have found related to this error were regarding Oracle 8.1.7
> and WebLogic 6.1. Any help would be greatly appreciated.
>
> Exceptions:
> -----------------
> <Mar 23, 2004 2:59:36 PM EST> <Error> <EJB> <BEA-010026> <Exception occurred during
> commit of transaction Xid=BEA1-0526A28664707F28EDB9(6412513),Status=Rolled back.
> [Reason=javax.transaction.xa.XAException
> : prepare failed for XAResource 'ProfilingPool' with error XAER_NOTA : The XID
> is not valid],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=2,seconds
> left=60,XAServerResourceInfo[JMS_my
> JmsStore]=(ServerResourceInfo[JMS_myJmsStore]=(state=rolledback,assigned=myserver),xar=JMS_myJmsStore),XAServerResourceInfo[ProfilingPool]=(ServerResourceInfo[ProfilingPool]=(state=rolledback,ass
> igned=myserver),xar=ProfilingPool),SCInfo[mydomain+myserver]=(state=rolledback),local
> properties=({}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+10.41.0.61:7001+m
> ydomain+t3+, XAResources={JMS_myJmsStore, JMS_FileStore, ProfilingPool, SearchManagementPool,
> AnnouncementsTxPool},NonXAResources={})],CoordinatorURL=myserver+10.41.0.61:7001+mydomain+t3+):
> javax.tran
> saction.xa.XAException: prepare failed for XAResource 'ProfilingPool' with error
> XAER_NOTA : The XID is not valid
> at weblogic.jdbc.oci.xa.XA.createException(XA.java:386)
> at weblogic.jdbc.oci.xa.XADataSource.internalPrepare(XADataSource.java:905)
> at weblogic.jdbc.oci.xa.XADataSource.prepare(XADataSource.java:885)
> at weblogic.jdbc.jta.DataSource.prepare(DataSource.java:846)
> at weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:1167)
> at weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:401)
> at weblogic.transaction.internal.ServerSCInfo$1.execute(ServerSCInfo.java:253)
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
> --------------- nested within: ------------------
> weblogic.transaction.RollbackException: Could not prepare resource 'ProfilingPool
> prepare failed for XAResource 'ProfilingPool' with error XAER_NOTA : The XID is
> not valid - with nested exception:
> [javax.transaction.xa.XAException: prepare failed for XAResource 'ProfilingPool'
> with error XAER_NOTA : The XID is not valid]
> at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1644)
> at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:300)
> at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:221)
> at weblogic.ejb20.internal.MDListener.execute(MDListener.java:412)
> at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
> at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
> at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
> at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
> ...
> 2004-03-23 15:00:45,406 ERROR IS003989 [ExecuteThread: '17' for queue: 'ProfileCompleteListenerBean.ExecuteQueue']
> my.package.search.business.ProfiledHoldingDAO.setProfilingStatus(ProfiledHoldingDAO.java:350
> ) - Failed to update profiling status for holding 10014 [] (-2)
> java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for
> lock
> at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:282)
> at weblogic.jdbc.oci.PreparedStatement.executeUpdate(PreparedStatement.java:226)
> at weblogic.jdbc.oci.xa.PreparedStatement.executeUpdate(PreparedStatement.java:81)
> at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:94)
> at my.package.search.business.ProfiledHoldingDAO.setProfilingStatus(ProfiledHoldingDAO.java:345)
> at my.package.search.business.ProfilingManager.disseminateAndAcknowledge(ProfilingManager.java:254)
> at my.package.search.business.ProfileCompleteListenerBean.onMessage(ProfileCompleteListenerBean.java:128)
> at weblogic.ejb20.internal.MDListener.execute(MDListener.java:382)
> at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
> at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
> at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
> at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
> ...
> 2004-03-23 15:01:43,093 ERROR IS003989 [ExecuteThread: '18' for queue: 'HoldingStatusListenerBean.ExecuteQueue']
> my.package.search.business.ProfiledHoldingDAO.getProfilingStatus(ProfiledHoldingDAO.java:265)
> - Failed to retrieve profiling results for holding 10060 [] (-2)
> java.sql.SQLException: ORA-01591: lock held by in-doubt distributed transaction
> 189.47.12
> at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:282)
> at weblogic.jdbc.oci.PreparedStatement.executeQuery(PreparedStatement.java:152)
> at weblogic.jdbc.oci.xa.PreparedStatement.executeQuery(PreparedStatement.java:48)
> at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:80)
> at my.package.search.business.ProfiledHoldingDAO.getProfilingStatus(ProfiledHoldingDAO.java:256)
> at my.package.search.business.ProfiledHoldingDAO.storeHoldingMetadata(ProfiledHoldingDAO.java:489)
> at my.package.search.business.ProfiledHoldingDAO.storeNewHolding(ProfiledHoldingDAO.java:406)
> at my.package.search.business.ProfilingManager.profileHolding(ProfilingManager.java:128)
> at my.package.search.business.HoldingStatusListenerBean.onMessage(HoldingStatusListenerBean.java:121)
> at weblogic.ejb20.internal.MDListener.execute(MDListener.java:382)
> at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
> at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
> at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
> at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
>
>
-
ORA-01591: lock held by in-doubt distributed transaction
I am using oracle wcf adapter to connect to oracle to insert.
I am getting the ORA-01591: lock held by in-doubt distributed transaction.
Any ideas as to what could be the resolution. I have followed the below mentioned steps. but that's not a permanent solution.
Please advice.
The resolution described below is not acceptable and never should have been used. Although it does avoid the error, it's not okay to turn off AmbientTransaction when performing inserts
and/or updates. A different solution needs to be found.<o:p></o:p>
http://msdn.microsoft.com/en-US/library/dd788352(v=BTS.10).aspx <o:p></o:p>
"Not performing operations in a transactional context is advisable only for operations that do not make changes to the database. For operations that update data in the database, we recommend
setting the binding property to true otherwise you might either experience message loss or duplicate messages depending on whether you are performing inbound or outbound operations."<o:p></o:p>
********************************************<o:p></o:p>
This can be resolved by adjusting the configuration settings on the Oracle adapter, accessible via the Send Port properties. The properties and the values that should be used are shown below:<o:p></o:p>
** Binding tab:
incrPoolSize: 1
maxPoolSize: 10
useAmbientTransaction: False<o:p></o:p>
** Messages tab:
Isolation Level: ReadCommitted<o:p></o:p>
Also, you'll need to get a DBA to rollback the hanging "in-doubt" transactions, which will be viewable via the sql below. Otherwise, if you try processing the same data again, you'll
still get the same error.<o:p></o:p>
SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, MIXED, HOST, COMMIT# FROM DBA_2PC_PENDING;<o:p></o:p>
The transactions can be rolled back with sql, using this syntax:<o:p></o:p>
ROLLBACK FORCE '<LOCAL_TRAN_ID>';
<o:p></o:p>
Thank you and have great day! Vivek Kulkarni MCAD.netHi Vivek,
This error is encountered by many DBA's and cause problem by locking the distributed transaction process, and not letting the query go through, because the Two - Phase Commit Mechanism got an error somewhere.
he DBA should query the pending_trans$ and related tables, and attempt to repair network connection(s) to coordinator and commit point.
Here are some codes to help you through the process:
This one brings in-doubt transactions:
select * from DBA_2PC_PENDING where state='prepared'
This one prepares the rollback script for the transactions:
select 'rollback force '''||local_tran_id||''';' from DBA_2PC_PENDING where state='prepared'
All this is well described in below link
ORA-01591: lock held by in-doubt distributed transaction
ORA-01591: lock held by in-doubt distributed transaction string tips
On BizTalk Side you need to make ambient transaction to false as Oracle does not go ahead with DTC Transaction with Biz Talk
Thanks
Abhishek -
ORA-02050 transaction string rolled back, some remote DBs may be in-doubt
Hi...guys...How ru all...
I got follwoing error...and I searched in google but there is not clear information..plz help me ...
Error Message: ORA-02050 transaction string rolled back, some remote DBs may be in-doubt
Error Cause:
Network or remote failure during a two-phase commit.
Action:
Notify operations; remote databases will automatically re-sync when the failure is repaired.
SQL>SELECT local_tran_id, global_tran_id, state, mixed, host, commit#
FROM dba_2pc_pending
LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE MIX HOST COMMIT#
5.44.98254 JICRACDB.e1ab4089.5.44.98254 collecti no JICN\ROOM9 1132915640
ng 7-ITC
SQL> SELECT local_tran_id, in_out, database, dbuser_owner, interface
2 FROM dba_2pc_neighbors
3 /
LOCAL_TRAN_ID IN_OUT DATABASE DBUSER_OWNER INT
5.44.98254 in JIC N
5.44.98254 out RC_DBLINK JIC N
SQL> ;
1 select state, tran_comment, advice from dba_2pc_pending
2* where local_tran_id ='5.44.98254'
SQL> /
STATE TRAN_COMMENT ADVICE
collecting
so how can I delete distributed transaction..plz provide me any Metalink Docids.See if following MOS note helps.
Manually Resolving In-Doubt Transactions: Different Scenarios (Doc ID 126069.1) -
Ora-01591 Lock held in by In-doubt distributed transaction - help required
In my web application i am getting an error @ a particular page. I am using JTA user transaction to mark the transaction boundaries. On commit i am confronting the error "lock held in by In-Doubt transaction. I queried pending_trans$,dba_2pc_pending and force commit the transaction.Also i purged the transaction using Purge_Lost_db_entity. Still after doing all these i am facing the same problem with a new transaction no.
I did all the below steps:
I did follow the below steps:
SELECT * FROM PENDING_TRANS$
SELECT
LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, MIXED, HOST, COMMIT#
FROM
DBA_2PC_PENDING
WHERE
LOCAL _TRAN_ID = '??.';
SELECT LOCAL_TRAN_ID, IN_OUT, DATABASE, INTERFACE
FROM DBA_2PC_NEIGHBORS;
COMMIT FORCE 'local transactionID', 'SCN';
DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY (local transactionID); OR
DBMS_TRANSACTION.PURGE_MIXED (local transactionID);
SELECT s.inst_id,
s.sid,
s.serial#,
p.spid,
s.username,
s.program
FROM gv$session s
JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id
WHERE s.type != 'BACKGROUND'
and s.program='JDBC Thin Client'
ALTER SYSTEM KILL SESSION '102,10' IMMEDIATE;
Database shutdown and restart doesnt work..
Please anyone help..tis is the result of the query v$version
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
"CORE 10.2.0.3.0 Production"
TNS for 32-bit Windows: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
I use websphere6.1 and oracle 10.2.0.3. using JTA UserTransaction to define boundaries. I am facing tis issue from last week only before it was working fine. I did the commit force as mentioned before to manually unlock transaction.From then i am getting this error. Could u pls help. I m having pressure from onsite, i dont know what is causing the error in one particular flow. I have included the error logs below.
[7/14/10 19:15:54:328 IST] 00000023 WSRdbXaResour E DSRA0304E: XAException occurred. XAException contents and details are:
The XA Error is : -3
The XA Error message is : A resource manager error has occured in the transaction branch.
The Oracle Error code is : 17410
The Oracle Error message is: Internal XA Error
The cause is : null.
[7/14/10 19:15:54:343 IST] 00000023 WSRdbXaResour E DSRA0302E: XAException occurred. Error code is: XAER_RMERR (-3). Exception is: <null>
[7/14/10 19:15:54:359 IST] 00000023 XATransaction E J2CA0027E: An exception occurred while invoking commit on an XA Resource Adapter from dataSource jdbc/ScorecardDataSource, within transaction ID {XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54), data(00000129d13434870000000100000008f0685880e9e9a1514500185d37d88f31da70140400000129d13434870000000100000008f0685880e9e9a1514500185d37d88f31da701404000000010000000000000000000000000001)}: oracle.jdbc.xa.OracleXAException
[7/14/10 19:15:54:531 IST] 00000023 MCWrapper E J2CA0081E: Method cleanup failed while trying to execute method cleanup on ManagedConnection WSRdbManagedConnectionImpl@3e0a3e0a from resource jdbc/ScorecardDataSource. Caught exception: com.ibm.ws.exception.WsException: DSRA0080E: An exception was received by the Data Store Adapter. See original exception message: No more data to read from socket. with SQL State : null SQL Code : 17410
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:125)
[7/14/10 19:15:54:593 IST] 00000023 MCWrapper E J2CA0081E: Method destroy failed while trying to execute method destroy on ManagedConnection WSRdbManagedConnectionImpl@3e0a3e0a from resource No longer available. Caught exception: java.lang.NullPointerException
[7/14/10 19:16:08:093 IST] 00000023 SystemErr R Caused by: java.sql.SQLException: ORA-01591: lock held by in-doubt distributed transaction 9.34.890
Pls help -
ORA-01591: lock held by in-doubt distributed transaction 14.4.44
Hi,
I am using WLI 8.1 SP2 on Windows 2000, Oracle 9.2. I am getting this error...
<Apr 23, 2004 10:43:43 AM EDT> <Error> <WLW> <000000> <error
java.io.IOException: [BEA][Oracle JDBC Driver][Oracle]ORA-01591: lock held by
in
-doubt distributed transaction 14.4.44
at weblogic.jdbc.base.BaseBlobOutputStream.write(Unknown Source)
at weblogic.jdbc.base.BaseBlobOutputStream.write(Unknown Source)
at com.bea.wlw.runtime.core.bean.BMPContainerBean$OracleTableAccess.doSt
oreByInsert(BMPContainerBean.java:904)
at com.bea.wlw.runtime.core.bean.BMPContainerBean.doInsert(BMPContainerB
ean.java:1785)
at com.bea.wlw.runtime.core.bean.BMPContainerBean.ejbStore(BMPContainerB
ean.java:1742)
at com.bea.wli.bpm.runtime.ProcessContainerBean.ejbStore(ProcessContaine
rBean.java:79)
at com.bea.wlwgen.PersistentContainer_nga2bb_Impl.ejbStore(PersistentCon
tainer_nga2bb_Impl.java:149)
at weblogic.ejb20.manager.ExclusiveEntityManager.beforeCompletion(Exclus
iveEntityManager.java:556)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManag
er.java:745)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(Serv
erSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(Se
rverSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAn
dChain(ServerTransactionImpl.java:1142)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(
ServerTransactionImpl.java:1868)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(Se
rverTransactionImpl.java:250)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
sactionImpl.java:221)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:412)
at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.
java:316)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
I have tried dropping all wli tables & deleting tlog files (deleting everything
from cgServer directory). Still get this error.
Any suggestions??
TIA
-AmitGetting this problem with WLI. I have just truncated tables and it's fine now.
Thanks,
Amit
"Sheetal Jain" <[email protected]> wrote:
>
Amit,
If these problem is happening with the WLI database then I would suggest
you should
talk to BEA support. If it is happening in the application you have built
just
look for any deadlock conditions happening in some scenarios inside different
inter-related transactions running at the same time, I mean transaction
1 is locking
something and in the meantime another one B locks something else which
is required
for the transaction A to move farward and now second one needs the resource
locked
by 1st.
Hope this helps
"Nagraj Rao" <[email protected]> wrote:
Hello Amit !,
Lock From In-Doubt Transaction is a 2-p TX issue, A query or DML statement
that
requires locks on a database is probably blocked due to some lock held
by a resource
of an "in-doubt distributed transaction".
A DB Admin can manually Commit or Rollback an "in-doubt distributedtransaction".
So I suggest you talk to the DBA
More at : http://www-rohan.sdsu.edu/doc/oracle/server803/A54653_01/ds_ch3.htm
BTW here's what Oracle says :
ORA-01591 lock held by in-doubt distributed transaction string
Cause: An attempt was made to access resource that is locked by a dead
two-phase
commit transaction that is in prepared state.
Action: The database administrator should query the PENDING_TRANS$ and
related
tables, and attempt to repair network connection(s) to coordinator and
commit
point. If timely repair is not possible, the database administratorshould
contact
the database administrator at the commit point if known or the end user
for correct
outcome, or use heuristic default if given to issue a heuristic COMMIT
or ABORT
command to finalize the local portion of the distributed transaction.
"Sheetal Jain" <[email protected]> wrote:
Amit,
It could be a bug. Open a ticket with BEA and see if they have a patch.
"Amit Bhutra" <[email protected]> wrote:
Hi,
I am using WLI 8.1 SP2 on Windows 2000, Oracle 9.2. I am getting
this
error...
<Apr 23, 2004 10:43:43 AM EDT> <Error> <WLW> <000000> <error
java.io.IOException: [BEA][Oracle JDBC Driver][Oracle]ORA-01591: lock
held by
in
-doubt distributed transaction 14.4.44
at weblogic.jdbc.base.BaseBlobOutputStream.write(Unknown Source)
at weblogic.jdbc.base.BaseBlobOutputStream.write(Unknown Source)
at com.bea.wlw.runtime.core.bean.BMPContainerBean$OracleTableAccess.doSt
oreByInsert(BMPContainerBean.java:904)
at com.bea.wlw.runtime.core.bean.BMPContainerBean.doInsert(BMPContainerB
ean.java:1785)
at com.bea.wlw.runtime.core.bean.BMPContainerBean.ejbStore(BMPContainerB
ean.java:1742)
at com.bea.wli.bpm.runtime.ProcessContainerBean.ejbStore(ProcessContaine
rBean.java:79)
at com.bea.wlwgen.PersistentContainer_nga2bb_Impl.ejbStore(PersistentCon
tainer_nga2bb_Impl.java:149)
at weblogic.ejb20.manager.ExclusiveEntityManager.beforeCompletion(Exclus
iveEntityManager.java:556)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManag
er.java:745)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(Serv
erSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(Se
rverSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAn
dChain(ServerTransactionImpl.java:1142)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(
ServerTransactionImpl.java:1868)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(Se
rverTransactionImpl.java:250)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
sactionImpl.java:221)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:412)
at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.
java:316)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
I have tried dropping all wli tables & deleting tlog files (deleting
everything
from cgServer directory). Still get this error.
Any suggestions??
TIA
-Amit -
ORA-01591: lock held by in-doubt distributed transaction 2.53.300807
SQL> select count(*) from TBCD_CCODMSG;
select count(*) from TBCD_CCODMSG
ERROR at line 1:
ORA-01591: lock held by in-doubt distributed transaction 2.53.300807
SQL> select * from TBCD_CCODMSG where rownum =10;
select * from TBCD_CCODMSG where rownum =10
ERROR at line 1:
ORA-01591: lock held by in-doubt distributed transaction 2.53.300807
SQL> alter session set events '1591 trace name errorstack level 10';
Session altered.
SQL> select * from TBCD_CCODMSG where rownum =10;
select * from TBCD_CCODMSG where rownum =10
ERROR at line 1:
ORA-01591: lock held by in-doubt distributed transaction 2.53.300807
SQL> select object_name, object_type from user_objects where object_name = 'TBCD_CCODMSG';
OBJECT_NAME
OBJECT_TYPE
TBCD_CCODMSG
TABLE
SQL> select * from DBA_2PC_PENDING;
no rows selected
SQL> select * from DBA_2PC_NEIGHBORS where local_tran_id = '2.53.300807';
LOCAL_TRAN_ID IN_
DATABASE
DBUSER_OWNER I DBID SESS#
BRANCH
2.53.300807 in
EFT.WORLD
CD1 N 15f1353d 1
0B000B00011902000128보통은 오라클 Background 프로세스인 RECO 프로세스가
해당 문제를 자동으로 복구해줍니다.
하지만, 가끔씩 제대로 처리를 못해주는 경우는 DBA 가 아래 절차를 확인하여
수동으로 처리를 해줘야 하는 경우도 있습니다.
아래 내용을 참고하세요...
No. 12163
DISTRIBUTED TRANSACTION TROUBLESHOOTING (ORA-1591해결 방법)
==========================================================
다른 database를 이용하지 않는 local transaction이, 비정상 종료시 자동으로
rollback되는 것과는 달리, 분산 트랜잭션의 경우 2 phase commit수행 단계중에
fail이 발생하게 되면 관여된 일부 database에서는 rollback 혹은 commit이 되고,
일부는 distributed lock이 걸린 상태로 계속 지속될 수 있다.
이렇게 pending된 transaction에 대해서는 기본적으로 Oracle의 background
process인 RECO process가 자동으로 정리하여 주나, 경우에 따라 자동으로 정리가
되지 못하는 상황이 발생할 수 있다.
이렇게 정리가 되지 않아, distributed lock이 걸린 경우에는, 이후 관계된
table을 조회나 변경시 ora-1591 오류가 발생할 수 있으므로, distributed
transaction이 실패한 경우 db admin이 관여하여 pending된 transaction을
정리하여 줄 필요가 있다.
distributed transaction이 오류가 발생하거나, 혹은 이후에 ora-1591이 발생하는
경우, 조치 방법을 9단계의 STEP으로 정리하였다.
*** distributed transaction의 2 phase commit에 대한 개념 및 자세한 절차는
<korean bulletin:12185>를 참조한다.
[참고 1] 문서의 이해를 위해서 분산 환경에 포함된 node를 V817LOC와 V817REM으로
예를 들고, V817LOC node에서 transaction을 수행하였다고 가정한다.
[참고 2] 아래에 언급되는 dbms_transaction package는 기본적으로 catproc.sql
script에 의해 생성되나 만약 존재하지 않는다면,
cd $ORACLE_HOME/rdbms/admin directory의 dbmsutil.sql, prvtutil.plb
script를 sys user에서 수행하도록 한다.
(svrmgrl에서 connect internal에서 수행하는것이 일반적)
그리고 이 package는 항상 transaction의 맨 처음에 수행되어야 한다.
즉, 새로 session을 연결하여 수행하거나, 혹은 앞에 dml에 있었다면,
commit이나 rollback을 수행 후 이 package를 수행하여야 한다.
아래의 STEP중 STEP 1 ~ 3까지는 문제 해결을 위해 필수적인 단계는 아니므로 바로
문제를 시급히 해결해야 하는 경우 4번부터 확인하도록 한다.
STEP 1: alert.log file을 check한다.
bdump directory의 alert.log에는 분산 트랜잭션 fail시 관계된 오류 메시지등
log가 항상 남게 된다. 예를 들면 다음과 같은 형태인데, rollback/commit되었
는지, in-doubt 상태인지와 그 외에 transaction id등 정보를 확인할 수 있다.
Tue Dec 12 16:23:25 2000
ORA-02054: transaction 1.8.238 in-doubt
ORA-02063: preceding line from V817REM
Tue Dec 12 16:23:25 2000
DISTRIB TRAN V817LOC.WORLD.89f6eafb.1.8.238
is local tran 1.8.238 (hex=01.08.ee)
insert pending prepared tran, scn=194671 (hex=0.0002f86f)
STEP 2: network 환경을 확인한다.
listener가 떠 있는지, database link가 모두 정상적인지 확인해 본다.
STEP 3: RECO process가 떠 있는지 확인한다.
os상에서 RECO process가 떠 있는지 확인하려면 다음과 같이 한다.
os> ps -ef | grep reco
RECO process는 db가 startup되면서 자동으로 구동되는 background process로
distributed recovery를 disable시키면 사라지게 된다. distributed recovery를
enable/disable시키는 방법은 아래와 같다.
SQL>alter system enable distributed recovery;
SQL>alter system disable distributed recovery;
아래의 조치사항 중에서 STEP 9번을 제외하고는 기본적으로 RECO process가
자동으로 처리하는 작업과 동일하다. 그러나 여러가지 문제로 인해 RECO가
자동으로 정리하지 못한 경우 이 문서의 방법대로 manual하게 정리하여 주어야
한다.
STEP 4: DBA_2PC_PENDING을 조회해 본다.
sqlplus system/manager
SQL>select local_tran_id, global_tran_id, state, mixed, host, commit#
from dba_2pc_pending;
다음과 같은 결과가 return된다.
LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#
-------------|----------------------|--------|---|----------|--------
1.8.238 |V817LOC.WORLD.89f6eafb|prepared|no |SUP_SERVER|194671
|.1.8.238 | | |\eykim |
이 조회로 인해 여러개의 row가 나오는 경우 ora-1591이나 distributed fail에
관련된 오류시 나타나는 local transaction id값과 return된 LOCAL_TRAN_ID값을
비교하여 일치하는 row를 확인하면 된다. 이때 LOCAL_TRAN_ID 값과
GLOBAL_TRAN_ID의 뒷부분의 숫자가 동일하다면 이것은 이 node가 global
coordinator임을 의미한다.
STEP 5: DBA_2PC_NEIGHBORS view를 조회해 본다.
sqlplus system/manager
SQL>select local_id, in_out, database, dbuser_owner, interface
from dba_2pc_neighbors;
LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT
-------------|------|-------------------------|---------------|---
1.8.238 |in | |SCOTT |N
1.8.238 |out |V817REM.WORLD |SCOTT |C
여기에 나타난 row들이 해당 분산 트랜잭션에 관여한 database 정보이다. 이때
DATABASE column 부분이 null로 나타나는 것은 현재 조회하고 있는 local
database를 의미하며, IN_OUT이 OUT으로 나타나는 경우 참조하는 node정보인데,
DATABASE 컬럼의 값이 해당 database를 가리키는 database link name이 된다.
이 database link name을 이용하여 다음과 같이 remote db의 DBA_2PC_PENDING을
다시 조사하여 관계된 node들의 상태를 확인할 수 있다.
SQL>select local_tran_id, global_tran_id, state, mixed, host, commit#
from dba_2pc_pending@v817rem;
각 node의 DBA_2PC_PENDING의 return된 row들이 같은 분산 트랜잭션에 포함된
정보인지는 GLOBAL_TRAN_ID 값을 이용하여 확인할 수 있다.
STEP 6: commit point site를 확인한다.
commit point site에 대해서는 <korean bulletin:12185>을 참조한다.
이 예의 경우 COMMIT_POINT_STRENGTH를 지정하지 않았기 때문에 default로
global coordinator가 아닌 V817REM이 commit point site가 된다. 일반적으로
commit point site는 global coordinator의 DBA_2PC_NEIGHBORS의 IN_OUT
field가 OUT으로 나타나고 INTERFACE 부분이 C로 나타나게 된다.
commit point site가 중요한 이유는 이 node의 local transaction부분은
prepared상태를 거치지 않아 in-doubt 상태가 되는 일이 없고, 그러므로
distributed lock에 의해 조회나 DML시 오류가 발생하는 없게 된다.
이러한 이유로 제일 중요한 data를 포함하는 중심이 되는 node를 commit point
site로 지정하는 것이 바람직하다.
STEP 7: DBA_2PC_PENDING의 MIXED column을 확인한다.
- MIXED값이 NO인 경우 : STEP 8 수행
- MIXED값이 YES인 경우: STEP 9 수행
DBA_2PC_PENDING에서 MIXED column을 YES나 NO의 값으로 지정하는 것은 RECO
process가 결정하여 변경하게 된다. MIXED가 YES가 되는 대표적인 경우는,
commit point site가 이미 commit을 수행한 상태에서 분산 트랜잭션이 fail된
경우, non-commit point site에서 prepared 상태의 transaction을 rollback
force시켜 분산 트랜잭션의 consistency가 깨진 상태이다.
(STATE column의 경우 commit point site는 COMMITTED로 non-commit point
site는 FORCED ROLLBACK으로 나타난다)
[참고] commit point site가 아직 commit을 수행하기 전에 분산 트랜잭션이
fail되어 commit point site가 rollback된 경우, non-commit point
site에서 prepared 상태의 transaction을 commit force 하면 이것도
논리적으로는 consistency가 지켜지지 않은 것은 동일하나 이때는
MIXED column이 no인 상태가 된다. 그 이유는 commit point site가
rollback되어 DBA_2PC_PENDING view에 entry가 남지 않기 때문에
RECO가 명시적으로 mixed 상태로 인식하는 것이 불가능하기 때문으로
파악된다.
STEP 8: DBA_2PC_PENDING의 STATE column의 값을 확인한다.
CASE 8-1: STATE field값이 COMMITTED인 경우
만약 STATE가 COMMITTED인 경우는 이 local database(V817LOC)에서는
transaction이 성공적으로 commit 되었음을 나타내므로, 이 node에서는 어떠한
작업도 수행할 필요가 없다. 이 entry는 RECO process에 의해 자동으로 지워질
것이며, 만약 RECO가 어떠한 이유로 이 row를 지우지 못했다면 다음과 같이
db admin이 직접 지워도 된다. 괄호 안의 값은 local_tran_id값이다.
sqlplus sys/manager (반드시 sys로 접속한다)
SQL>exec dbms_transaction.purge_lost_db_entry('1.8.238');
이렇게 V817LOC의 STATE부분이 COMMITTED인 경우는, 이미 commit point site인
V817REM은 commit된 후임을 나타낸다. 그러므로 V817REM은 STATE가 COMMITTED로
나타나거나 아니면 commit후 이미 정보가 지워져 DBA_2PC_PENDING에 정보가
나타나지 않을 수 있다. 그러므로 V817REM에 대해서는 필요한 경우 V817LOC의
앞의 조치 방법과 동일하게 DBA_2PC_PENDING의 내용만 정리하여 주면 된다.
만약 V817REM이 아닌 별도의 다른 node가 분산 트랜잭션에 관여했다고 가정하고
V817LOC가 COMMITTED인 상태에서 그 node의 STATE가 PREPARED로 나타난다면
그 node에 대해서는 아래의 CASE 8-2를 참조하여 해결하도록 한다.
CASE 8-2: STATE field값이 PREPARED인 경우
STATE값이 PREPARED인 경우는 이 node(V817LOC)에서 변경된 data가 속한 block
에 distributed lock이 걸린 상태이며, 이런 경우 변경된 data가 있는 block에
대한 모든 read/write가 ora-1591을 발생시키므로 trouble shooting에서 제일
중요한 부분이라 할 수 있다.
먼저 STEP 4와 STEP 5를 참조하여 관계된 모든 node들의 DBA_2PC_PENDING view
를 조회하여 본다. 이때 다른 node(V817REM)의 DBA_2PC_PENDING에 정보가 없다
면 V817REM이 commit point site이고 이미 data는 rollback되었음을 나타낸다.
이때는 V817LOC의 prepared 상태의 transaction을 다음과 rollback force 시켜
준다.
즉, V817LOC에서,
SQL>rollback force '1.8.238';
만약 V817REM node에 해당 정보가 있고 상태가 COMMITTED라면 V817LOC도
다음과 같이 commit을 해 주어야 한다.
SQL>commit force '1.8.238';
이때 local_tran_id 뒤에 SCN을 지정할 수 있는데 이것은 관여된 node 중 제일
큰 SCN을 지정하도록 한다. 이 SCN 값은 DBA_2PC_PENDING의 COMMIT# field에서
값을 확인할 수 있으며 이렇게 하는 이유는 이후 분산 database중 한 database
에서 incomplete recovery가 필요한 경우, 다른 database 들도 일관성을
맞추기 위해 incomplete recovery를 이용할 수 있게 하기 위한 것이다.
SQL>commit force '1.8.238', '194671'
CASE 8-3: STATE field값이 COLLECTING인 경우
STATE field가 collecting인 경우는 아직 distributed lock을 걸기 전단계에서
transaction이 비정상 종료됨을 나타내며, 이 단계에서는 distributed lock이
걸리기 전이어서 변경된 data는 이미 rollback된 상태이다. 이 경우는
DBA_2PC_PENDING에서 해당 entry를 지워 주면 된다.
sqlplus sys/manager (반드시 sys로 접속한다)
SQL>exec dbms_transaction.purge_lost_db_entry('1.8.238');
CASE 8-4: STATE field값이 FORCED ROLLBACK/FORCED COMMIT 인 경우
이미 RECO나 db admin이 rollback force나 commit force 명령을 시도하여
STATE가 FORCED ROLLBACK이나 FORCED COMMIT으로 변경된 경우는 추가적으로
수행할 작업은 없으며, RECO가 자동으로 이 entry를 지워 줄 것이다. 그러나
RECO가 작업하기를 기다리지 않고 다음과 같이 직접 삭제할 수 있다.
sqlplus sys/manager (반드시 sys로 접속한다)
SQL>exec dbms_transaction.purge_lost_db_entry('1.8.238');
STEP 9: 불일치 사항을 파악하고 DBA_2PC_PENDING을 정리한다.
어떠한 경우에 DBA_2PC_PENDING의 MIXED column이 YES가 되는지는 이미 STEP 7
에서 설명하였다. 이렇게 잘못된 조치에 의해 STEP 7에서 설명한 것과 같은
분산 데이타베이스간의 불일치가 발생한 경우는 간단한 operation을 통해
일치성을 맞추는 것은 불가능하다.
분산 트랜잭션의 consistency가 무엇보다 중요한 경우라면 관계된 node의
database를 모두 문제의 분산 트랜잭션이 수행되기 이전 상태로, incomplete
recovery를 수행하거나 할 수 있다. 분산 데이타베이스간의 일관성을 위한
incomplete recovery에 대해서는 여기에서는 다루지 않는다. 한가지 언급한
말한 것은 앞에서 설명한 분산 트랜잭션의 commit시 이용하는 commit SCN을
관계된 모든 node들의 최대 SCN으로 이용하는 것이 바로 이러한 recovery를
위한 것이다. 이렇게 일부 database에서 SCN값이 이전 SCN에서 1씩 증가하는
것이 아니라 큰 값으로 건너뛰어 다른 database와 같은 SCN을 유지하게
함으로써, 이후에 incomplete recovery시에 관계된 node들이 서로 동일한
SCN으로 recovery를 수행하면, 모두 분산 트랜잭션 적용 이전이 되거나 혹은
모두 이후가 되어 일관성을 유지할 수 있도록 해준다.
MIXED가 YES인 상태에서, inconsistency를 받아들이고 DBA_2PC_PENDING view를
정리하려면 다음과 같이 수행한다.
sqlplus sys/manager (반드시 sys user로 수행한다)
SQL>exec dbms_transaction.purge_mixed('1.8.238'); -
Understanding on Oracle services for Microsoft Transaction Server frm dba point of view
Hi ALL,
i read : -> https://docs.oracle.com/database/121/NTMTS/recovery.htm#NTMTS003
Need help to further confirm my understanding on what i read.
I am coming from the DBA angle... .
the functionality of the Microsoft Transaction server is integrated within the operating system as a COM+ server and as a .NET server, "
can i say these is the application servers ?
and the Microsoft Transaction distributed co -ordinator components is part of it.
Question, i don't install the Oracle Recovery Services on the above system right?
Question 2, as a dba, my only concern is to make sure the Oracle Services for Microsoft Transaction Server is installed. Is this correct ?
plus making sure to create the OraMTS administrator to run the recovery job to check for in-doubt transaction.
Question 3:
is this Oracle services for Microsoft Transaction Server used only when an application useses multiple databases in an env?
Can i say that when there is no user MTSSYS in my database, Oracle services for MTS is not used?
The reason why i ask is i am upgrading/ migrating my database and this database don't work with more then 1 database or the application does not work with more then 1 databases.
I ask the apps team all they say is that they are also not too sure. Thus need help/ advice.Daniel,
In pre-8.1.7.4.0 beta implementations, your application server e.g. IIS or MTX.EXE hosts MTS transactional components. When such components acquire OLEDB or ODBC connections to Oracle and external service setup for that database i.e. OracleMTSService<id> joins the MTS transaction on behalf of the Oracle database which quite often runs on a non-Windows platform e.g. Solaris. We restrict each database to have one and only such service. This brings in scalability and availability issues. In 8.1.7.4.0 we have embedded the transaction join and commit logic in the clientside dll. There is no OracleMTSService<id> for a given database. The only service needed is a recovery service one per Windows machine on which Oracle Svcs For MTS is installed. This service is automatically created on installation of the product and doesn't connect to the databases. Instead the involved databases connect to the service via HTTP to resolve any MTS-related transactions that are in-doubt. -
Hi All,
BANNER
Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
PL/SQL Release 8.1.7.4.0 - Production
CORE 8.1.7.0.0 Production
TNS for HPUX: Version 8.1.7.4.0 - Production
NLSRTL Version 3.4.1.0.0 - Production
11:19:26 SQL> !uname -a
HP-UX pds1 B.11.11 U 9000/800 3251073460 unlimited-user license
I have one question for you people, I see entries lying in dba_2pc_transcations and DBA_2PC_NEIGHBORS view. I would appriciate, if you can describe it in details,
what it is, how should someone need to go about this?, is this a database problem?, etc. Following entries produced, when consulted to dba_2pc_pending and dba_2pc_neighbors. Thanks a lot for your time.
LOCAL_TRAN_ID STATE MIX TRAN_COMMENT
23.91.4392377 collecting no
3.3.4640279 collecting no
9.76.4592966 collecting no
17.8.4140088 collecting no
13.93.4330901 collecting no
1.8.3207186 forced rollback no
23.64.4503882 collecting no
19.27.4291663 collecting no
7.6.4763197 committed no
9.30.4738604 collecting no
17.18.3378650 collecting no
12.80.3712070 collecting no
8.73.3861990 collecting no
10.43.3874670 collecting no
21.69.3375703 collecting no
4.55.3913116 collecting no
9.32.3854560 collecting no
12.35.3718597 collecting no
5.85.3942634 collecting no
16.26.9459959 collecting no
LOCAL_TRAN_ID IN_OUT DATABASE DBUSER_OWNER INT
4.49.3932670 in DTHOMAS N
5.68.3954694 in DTHOMAS N
2.2.3971416 in DTHOMAS N
2.1.3972996 in WINBTCH N
1.92.2447742 in WINBTCH N
15.82.3540385 in JZHANG N
20.48.3428226 in DBTRAN N
5.91.3976273 in WINBTCH N
13.26.3664453 in DBTRAN N
10.95.3980068 in DBTRAN N
15.56.3605010 in DBTRAN N
20.89.3725950 in DBTRAN N
2.14.4262317 in DBTRAN N
5.97.4236649 in DBTRAN N
20.8.3727867 in DBTRAN N
15.24.3816364 in DBTRAN N
8.18.4181707 in DBTRAN N
3.35.4243326 in DBTRAN N
15.72.3840816 in DBTRAN N
19.61.3840102 in DBTRAN N
21.59.3823379 in DTHOMAS N
9.33.4272542 in DTHOMAS N
3.69.4344109 in LMAGGIO N
14.40.3937291 in DTHOMAS NYou can find information on the meaning the columns for these two views in your Oracle 8.1.7 Reference manual.
As long as a join of dba_2pc_neighbors to dba_2pc_pending on the local_tran_id column results in "no rows" you should be fine. Results from the join would be in-doubt transactions that require clean-up. The DBA Administration Guide for 8.1.7 should cover how to clear in-doubt distributed transactions as the last 5 or so chapters are devoted to database links and distributed transaction management, if my memory is correct.
HTH -- Mark D Powell --
Maybe you are looking for
-
At a loss with some simple java classwork. Please help.
Hello. I'm having a problem with some work that I wasn't able to finish in class. I am not very good at java AT ALL, and I'm really at a loss on how to finish up the program and get it to print what I want it to. My task is: "Write a program that ask
-
How do enable my apple ID on my iPhone 6
How do I enable my apple id , on my iPhone 6?
-
Transport Error when Importing TR to QA system
Hi All, We are receiving the below error when transporting a TR to Quality system. Detail Error message: Execution of programs after import (XPRA) Transport request : XXXXXX System : XXX tp path : tp Version and r
-
Redirect subdomain to a secure domain
Is there any way to redirect a subdomain to a secure domain without getting certificate errors? I have my subdomain CNAME (campus.unikemia.com) redirecting to another domain which is secure (unikemia.blackboard.com)
-
Mail cannot be delivered - stays in out tray
I have just been reviewing and testing assembled wisdom on this problem for which there are multiple posts. The two solutions suggested do not work for me (1) My ISP says that SMTP server settings are correctly configured for my account, port 25, no