ORACLE悬疑分布式事务问题处理

谁践踏了优雅 2022-10-16 07:45 246阅读 0赞

当需要在[多个Oracle数据][Oracle]库之间进行数据一致性操作时，就会用到分布式事务。  
例如：

insert into T\_log@remote\_db; --远程数据库插入  
insert into T\_local; --本地数据库插入  
commit;  
分布在本地和远程两个db的事务同时操作，这就构成了一个分布式事务。

分布式事务采用[Two-Phase Commit][Oracle]提交机制，保证分布在各个节点的子事务能够全部提交或全部回滚的原子性。在这种机制下，事务处理过程分为三个阶段：

PREPARE：发起分布式事务的节点通知各个关联节点准备提交或回滚。各关联节点此时会做三个事情：刷新redo信息到redo log中；将持有的锁转换为悬疑事务锁；取各节点中最大的SCN号进行同步  
COMMIT：写入commited SCN，释放锁资源  
FORGET：悬疑事务表和关联的数据库视图信息清理  
由于分布式事务涉及到多个数据库之间进行操作，偶尔会遇到一些异常情况（例如系统或网络中断）导致上述三个阶段出现异常，这就在一个或多个节点上，产生不完整的“悬疑分布式事务”。  
大多数情况下，出现这种问题，[Oracle会由Reco进程][Oracle]进行自动修复，Oracle数据库会在[dba\_2pc\_pending 和dba\_2pc\_neighbors][Oracle]等多个视图中记录分布式事务相关的信息，事实上reco进程也是基于这些信息去做自动修复的。  
Reco进程会尝试连接到其他节点获取分布式事务信息，然后尝试修复失败的事务，并将对应的事务中的记录删除。  
但有些情况下（例如节点无法正常访问或事务表中记录的数据不完整），Reco进程不能正常完成这个工作，就会抛出异常。对于分布式事务，对应的异常代码区间是ORA-02040 - ORA-02099，可通过alert日志查看到错误信息。  
例如：

ORA-02054: transaction in-doubt  
The transaction is neither committed or rolled back locally, and we have lost communication with the global coordinator.  
此时往往需要手工处理进行干预。

以下是三种常见的分布式事务问题场景：

dba\_2pc视图中有数据，但分布式事务已经不存在  
分布式事务存在，但dba\_2pc视图中没有数据  
事务和视图数据都有，但是执行commit force或rollback force时hang住  
通过报错会有提示，例如：

ORA-01591: lock held by in-doubt distributed transaction 10.20.360  
这个10.20.360就是我们需要检查分布式事务ID  
场景一：dba\_2pc视图中有数据，但分布式事务已经不存在  
视图有数据，那么先检查数据的状态

select \* from dba\_2pc\_pending where local\_tran\_id=‘10.20.360’;  
主要看state字段。  
如果事务已经是committed, rollback forced或者commit forced状态，表示事务已经完成了，但是在FORGET阶段处理时，数据库字典的信息没能及时清除。此时，我们调用oracle的清理丢失事务信息的语句就可以完成处理：

execute DBMS\_TRANSACTION.PURGE\_LOST\_DB\_ENTRY (‘10.20.360’);  
如果事务是PREPARED状态，但是在事务表中又没有活动的事务：

SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /\* Transaction ID \*/  
KTUXESTA Status,  
KTUXECFL Flags  
FROM x$ktuxe  
WHERE ktuxesta!=‘INACTIVE’  
AND ktuxeusn= 10; --注意替换这里的回滚段号(xid=usn.slot.(sqn+1))  
\----没有活动的事务  
那此时需要手工清理丢失事务的信息

set transaction use rollback segment SYSTEM;  
delete from sys.pending\_trans$ where local\_tran\_id = ;  
delete from sys.pending\_sessions$ where local\_tran\_id = ;  
delete from sys.pending\_sub\_sessions$ where local\_tran\_id = ;  
commit;  
场景二：分布式事务存在，但dba\_2pc视图中没有数据

遇到ORA-2054, ORA-1591等错误，检查dba\_2pc视图没有记录，这种场景不常见，只在少数极端的情况下出现。  
先确认现象，分别检查x$ktuxe和 dba\_2pc\_pending视图，查询语句与场景一相同  
在这种情况下无论是执行commit force还是rollback force，都会直接抛出异常：

commit force ‘10.20.360’;  
ORA-02058: no prepared transaction found with ID 10.20.360  
这时我们需要将视图对应的基表数据补入，然后再执行rollback force。

alter system disable distributed recovery;  
insert into pending\_trans$ (  
LOCAL\_TRAN\_ID, GLOBAL\_TRAN\_FMT,  
GLOBAL\_ORACLE\_ID,STATE, STATUS,  
SESSION\_VECTOR,RECO\_VECTOR,TYPE\#, FAIL\_TIME, RECO\_TIME)  
values( ‘10.20.360’, /\* <== Replace this with your local tran id \*/  
306206, ‘xxxxxxxx.00000.0.0.0’,  
‘prepared’,‘P’,  
hextoraw( ‘00000001’ ),hextoraw( ‘00000000’ ), 0, sysdate, sysdate );  
insert into pending\_sessions$  
values( ‘10.20.360’,1, hextoraw(‘00000000’), ‘C’, 0, 1433927502, ‘’, 14);  
–1433927502为DBID, 14为userid  
commit;  
rollback force ‘10.20.360’;  
EXECUTE DBMS\_TRANSACTION.PURGE\_LOST\_DB\_ENTRY(‘10.20.360’);  
–手工清理事务信息  
场景三：事务和视图数据都有，但是执行commit force或rollback force时hang住

如果视图和事务表中都有数据，而且状态是PREPARED，先执行commit force或rollback force，通常就能解决问题，但有时候也会遇到执行force处理时hang住  
尝试purge事务信息时，有提示报错：

BEGIN DBMS\_TRANSACTION.PURGE\_LOST\_DB\_ENTRY(‘10.20.360’); END;  
\*  
ERROR at line 1:  
ORA-06510: PL/SQL: unhandled user-defined exception  
ORA-06512: at “SYS.DBMS\_TRANSACTION”, line 94  
ORA-06512: at line 1  
此时需要进行场景一和场景二的结合起来的所有步骤：

1.  先将视图对应的基表数据删除  
    delete from sys.pending\_trans$ where local\_tran\_id = ‘10.20.360’;  
    delete from sys.pending\_sessions$ where local\_tran\_id = ‘10.20.360’;  
    delete from sys.pending\_sub\_sessions$ where local\_tran\_id =‘10.20.360’;  
    commit;
2.  再插入pending\_trans 和 p e n d i n g s e s s i o n s 和pending\_sessions 和pendingsessions数据，见场景二
3.  rollback force ‘10.20.360’;
4.  Purge the transaction:  
    exec dbms\_transaction.purge\_lost\_db\_entry(‘10.20.360’);

完整实例：[http://github.crmeb.net/u/defu][Oracle]

来自 “开源世界 ” ，链接：[http://ym.baisou.ltd/post/645.html][http_ym.baisou.ltd_post_645.html]，如需转载，请注明出处，否则将追究法律责任。

[Oracle]: http://github.crmeb.net/u/defu
[http_ym.baisou.ltd_post_645.html]: http://ym.baisou.ltd/post/645.html