dba_2pc_pending视图中的信息不清除会对以后有影响吗？如何根本解决问题？

jieyancai · 发表于 2008-6-18 16:40

oracle9206+solaris9

alert日志信息：
Wed Jun 18 16:01:40 2008
Error 2068 trapped in 2PC on transaction 25.13.3300307. Cleaning up.
Error stack returned to user:
ORA-02050: transaction 25.13.3300307 rolled back, some remote DBs may be in-doubt
ORA-02068: following severe error from RADIUSC
ORA-12570: TNS:packet reader failure
Wed Jun 18 16:01:40 2008
DISTRIB TRAN BIMS.888c7a47.25.13.3300307
  is local tran 25.13.3300307 (hex=19.0d.325bd3)
  insert pending collecting tran, scn=26459977850 (hex=6.2923387a)
Wed Jun 18 16:02:18 2008

Wed Jun 18 16:17:28 2008
Error 2068 trapped in 2PC on transaction 3.12.10511774. Cleaning up.
Wed Jun 18 16:17:28 2008
DISTRIB TRAN BIMS.888c7a47.3.12.10511774
  is local tran 3.12.10511774 (hex=03.0c.a0659e)
  insert pending collecting tran, scn=26460503683 (hex=6.292b3e83)

ARC1: Completed archiving  log 1 thread 1 sequence 242783
Wed Jun 18 16:26:17 2008
Error stack returned to user:
ORA-02050: transaction 3.12.10511774 rolled back, some remote DBs may be in-doubt
ORA-02068: following severe error from RADIUSD
ORA-12570: TNS:packet reader failure

视图信息：

SQL> select LOCAL_TRAN_ID,STATE from dba_2pc_pending;

LOCAL_TRAN_ID       STATE
---------------------- ----------------
25.13.3300307       collecting
3.12.10511774       collecting

SQL> col LOCAL_TRAN_ID for a15
SQL> col IN_OUT for a10
col DATABASE for a10
col INTERFACE for a20
set line 132
SELECT LOCAL_TRAN_ID, IN_OUT, DATABASE, INTERFACE FROM DBA_2PC_NEIGHBORS;SQL> SQL> SQL> SQL>

LOCAL_TRAN_ID IN_OUT    DATABASE INTERFACE
--------------- ---------- ---------- --------------------
25.13.3300307 in                   N
3.12.10511774 in                   N
25.13.3300307 out       RADIUSA N
25.13.3300307 out       RADIUSB N
25.13.3300307 out       RADIUSC N
25.13.3300307 out       RADIUSD N
3.12.10511774 out       RADIUSA N
3.12.10511774 out       RADIUSB N
3.12.10511774 out       RADIUSD N
3.12.10511774 out       RADIUSC N

已选择10行。

视图里的信息不清除对以后的业务有影响吗？因为根据metalink.oracle.com操作，虽然我清除过了，但是一段时间后又会产生新的挂起信息。
SQL> alter session set "_smu_debug_mode" = 4;

会话已更改。

SQL> EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('25.13.3300307');

PL/SQL 过程已成功完成。

SQL> commit;

如何根本解决问题？

[ 本帖最后由 jieyancai 于 2008-6-19 08:26 编辑 ]

alantany · 发表于 2008-6-18 16:42

网络或者监听器的问题导致分布式事务在事务协调上发生了错误。
最可能是网络不稳定或者主机响应缓慢

jieyancai · 发表于 2008-6-18 16:48

原帖由 alantany 于 2008-6-18 16:42 发表
网络或者监听器的问题导致分布式事务在事务协调上发生了错误。
最可能是网络不稳定或者主机响应缓慢

1.您说的是原因，还可能手动停止了事务，但视图里的信息不清除对以后的业务有影响吗？
2.视图中state的状态时collecting的，这种情况下是试过是不能commit和rollback的。
那对于其它状态比如prepared就应该尝试commit或rollback吗？

kso · 发表于 2008-6-18 16:56

execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('LOCAL_TRAN_ID')
?

jieyancai · 发表于 2008-6-18 17:05

找到一个网友的解释：

two phase commit和分布式事务，two phase commit是为保证分布式事务的数据一致性而设计的，在Oracle事务中对两个以上的Oracle站点执行了操作就形成了分布式事务，一般情况下，Oracle会自动处理分布式事务，为了保证分布式事务的一致性，所有站点的修改操作要么全部提交，要么全部回滚，否则就会造成数据不一致，在分布式事务中，不同站点的角色不同，有global coordinator和commit point site，commit point site会首先执行提交，本地数据库作为global coordinator，Oracle初始化参数commit_point_strength决定了哪个站点成为commit point site，commit_point_strength值最高的站点会成为commit point site，two phase commit有如下3个阶段：

1.准备阶段(PREPARE PHASE)，在这个阶段会处理如下这些事情：

·本地数据库Global Coordinator向其它数据库发出COMMIT通知

·比较所有数据库的SCN号，将最高的SCN号作为分布式事务的全局SCN号

·所有数据库写在线日志

·对分布式事务修改的表加分布锁，防止被读写

·各数据库向Global Coordinator发出已经准备好的通知

所有参与分布式事务的数据库必须经过上述准备，才能进入下一阶段

2.提交阶段(COMMIT PHASE)，在这个阶段会处理如下这些事情：

·本地数据库Global Coordinator通知commit point site首先提交，commit point site提交后，释放其占有的资源，通知Global Coordinator完成提交

·本地数据库Global Coordinator通知其它数据库提交

·提交节点在日志中追加一条信息，表示分布式事务已经完成提交，并通知Global Coordinator，此时所有数据库的数据保持了一致性

3.注销阶段(FORGET PHASE)

·本地数据库Global Coordinator通知commit point site所有数据库已经完成提交

·commit point site清除分布式事务的记录和状态信息，并通知Global Coordinator

·Global Coordinator清除本地分布式事务的记录和状态信息

此时分布式事务的two phase commit全部完成

以上3个阶段，在任何一个阶段的前、中、后发生失败都会导致two phase commit失败，一般来说，Oracle后台进程REC0会自动恢复事务，只有在分布式事务锁住的对象急需被访问，锁住的回滚段阻止了其他事务的使用，网络故障或CRASH的数据库的恢复需要很长的时间等情况出现时，才需要使用人工操作的方式来维护分布式事务，而分布式事务失败的情况也比较复杂，需要针对不同的情形采取相应的措施，Oracle中提供了视图dba_2pc_pending和dba_2pc_neighbors供用户查看分布式事务的相关信息，通常two phase commit失败有如下5种情况：

1.prepare阶段没准备好就失败了，global coordinator正在等待各个站点返回已准备好的通知，处于collecting状态，dba_2pc_pending试图中的state列的值是collecting，各个站点什么都没发生，无需执行任何操作，在本地数据库执行exec dbms_transaction.purge_lost_db_entry(’transaction_id’)清除in_doubt状态的分布式事务记录就可以了

2.prepare阶段完成时发生失败，global coordinator处于prepared状态，已经加上分布锁，等待提交，远程commit point site已经自动回滚，此时需要在global coordinator上执行rollback force ‘transaction_id’，然后清除in_doubt状态的分布式事务记录

3.commit point site执行commit完成后其他站点尚未commit时发生失败，这时需要在其他站点执行commit force ‘transaction_id’,'commit#’，注意后面的commit#使用较高的commit#，可以查询各个站点的dba_2pc_pending试图的commit#列得到，然后清除in_doubt状态的分布式事务记录

4.所有站点commit成功，进入forget阶段时发生失败，数据已经一致，只需在各站点清除in_doubt状态的分布式事务记录就可以了

5.commit point site完成forget阶段，其他站点没完成forget，只需在其他站点清除in_doubt状态的分布式事务记录就可以了

jieyancai · 发表于 2008-6-18 17:14

http://download.oracle.com/docs/ ... /ds_txnman.htm#9304

Determining When to Use DBMS_TRANSACTION
The following tables indicates what the various states indicate about the distributed transaction what the administrator's action should be:

STATE Column State of Global Transaction State of Local Transaction Normal Action Alternative Action
Collecting
Rolled back
Rolled back
None
PURGE_LOST_DB_ENTRY (only if autorecovery cannot resolve transaction)

Committed
Committed
Committed
None
PURGE_LOST_DB_ENTRY (only if autorecovery cannot resolve transaction)

Prepared
Unknown
Prepared
None
Force commit or rollback

Forced commit
Unknown
Committed
None
PURGE_LOST_DB_ENTRY (only if autorecovery cannot resolve transaction)

Forced rollback
Unknown
Rolled back
None
PURGE_LOST_DB_ENTRY (only if autorecovery cannot resolve transaction)

Forced commit
Mixed
Committed
Manually remove inconsistencies then use PURGE_MIXED
-

Forced rollback
Mixed
Rolled back
Manually remove inconsistencies then use PURGE_MIXED
-