Wed Nov 17 00:00:04 2004 Errors in file d:\Oracle\admin\xdcj\udump\xdcj_j006_3020.trc: ORA-12012: 自动执行作业 82 出错 ORA-01591: 锁定已被有问题的分配事务处理6.5.887985挂起 ORA-06512: 在line 6
这正是出错的地方，往前追溯：
Tue Nov 16 17:35:04 2004 Error 28500 trapped in 2PC on transaction 6.5.887985. Cleaning up. Error stack returned to user: ORA-02054: 事务处理6.5.887985有问题 ORA-28500: 连接 ORACLE 到非 Oracle 系统时返回此信息: [Transparent gateway for MSSQL] ORA-02063: 紧接着2 lines（源于ZSMOS_CRM） Tue Nov 16 17:35:04 2004 DISTRIB TRAN QDCJ.US.ORACLE.COM.5ae32328.6.5.887985 is local tran 6.5.887985 (hex=06.05.d8cb1) insert pending prepared tran, scn=6606197672830 (hex=602.2010cb7e) Tue Nov 16 17:35:07 2004 Errors in file d:\oracle\admin\xdcj\bdump\xdcj_reco_3024.trc: ORA-28500: connection from ORACLE to a non-Oracle system returned this message: [Transparent gateway for MSSQL][Microsoft][ODBC SQL Server Driver][SQL Server]用户 'RECOVER' 登录失败。 (SQL State: 28000; SQL Code: 18456) ORA-02063: preceding 2 lines from ZSMOS_CRM
Tue Nov 16 17:35:12 2004 Errors in file d:\oracle\admin\xdcj\bdump\xdcj_reco_3024.trc: ORA-28500: connection from ORACLE to a non-Oracle system returned this message: [Transparent gateway for MSSQL][Microsoft][ODBC SQL Server Driver][SQL Server]用户 'RECOVER' 登录失败。 (SQL State: 28000; SQL Code: 18456) ORA-02063: preceding 2 lines from ZSMOS_CRM
这就是事发地点了。看来是昨天下午远程事务失败，但是又没有返回造成分布式事务挂死，从而锁定了行。终于找到了详细的错误ORA-02054，进入TOAD一查，说是要等待或者提交该事务，可是怎么操作呢。还是打开官方文档搜索相关内容，在Adminstrator Guide中发现如下内容： Discovering Problems with a Two-Phase Commit The user application that commits a distributed transaction is informed of a problem by one of the following error messages:
ORA-02050: transaction ID rolled back, some remote dbs may be in-douBT ORA-02051: transaction ID committed, some remote dbs may be in-doubt ORA-02054: transaction ID in-doubt
A robust application should save information about a transaction if it receives any of the above errors. This information can be used later if manual distributed transaction recovery is desired.
No action is required by the administrator of any node that has one or more in-doubt distributed transactions due to a network or system failure. The automatic recovery features of Oracle transparently complete any in-doubt transaction so that the same outcome occurs on all nodes of a session tree (that is, all commit or all roll back) after the network or system failure is resolved.
In extended outages, however, you can force the commit or rollback of a transaction to release any locked data. Applications must account for sUCh possibilities.
Determining Whether to Perform a Manual Override Override a specific in-doubt transaction manually only when one of the following situations exists:
The in-doubt transaction locks data that is required by other transactions. This situation occurs when the ORA-01591 error message interferes with user transactions. An in-doubt transaction prevents the extents of a rollback segment from being used by other transactions. The first portion of an in-doubt distributed transaction's local transaction ID corresponds to the ID of the rollback segment, as listed by the data dictionary views DBA_2PC_PENDING and DBA_ROLLBACK_SEGS. The failure preventing the two-phase commit phases to complete cannot be corrected in an acceptable time period. Examples of such cases include a telecommunication network that has been damaged or a damaged database that requires a long recovery time. Normally, you should make a decision to locally force an in-doubt distributed transaction in consultation with administrators at other locations. A wrong decision can lead to database inconsistencies that can be difficult to trace and that you must manually correct.
If the conditions above do not apply, always allow the automatic recovery features of Oracle to complete the transaction. If any of the above criteria are met, however, consider a local override of the in-doubt transaction.
精品推荐