Oracle 10G RAC 主机意外重启引起分布式事务故障处理

故障:Oracle 10G rac 中的一台主机意外重启,重启后数据库手工启动,从状态上看一切正常,
plsql也能登陆,但前端Tuxedo无法连报报错,但Tuxedo连测试库没有问题,所以问题还是出在
数据库上。

分析:
DBA_2PC_PENDING
Oracle会自动处理分布事务,保证分布事务的一致性,所有站点全部提交或全部回滚。一般情况下,处理过程在很短的时间内完成,根本无法察觉到。
但是,如果在commit或rollback的时候,出现了连接中断或某个数据库站点CRASH的情况,则提交操作可能会无法继续,
此时DBA_2PC_PENDING和DBA_2PC_NEIGHBORS中会包含尚未解决的分布事务。 对于绝大多数情况,当恢复连接或CRASH的数据库重新启动后,
会自动解决分布式事务,不需要人工干预。只有分布事务锁住的对象急需被访问,锁住的回滚段阻止了其他事务的使用,
网络故障或CRASH的数据库的恢复需要很长的时间等情况出现时,才使用人工操作的方式来维护分布式事务。 手工强制提交或回滚将失去二层提交的特性
,Oracle无法继续保证事务的一致性,事务的一致性应由手工操作者保证
使用ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY,可以使Oracle不再自动解决分布事务,即使网络恢复连接或者CRASH的数据库重新启动。
ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY恢复自动解决分布事务。

Oracle解决异步lock的方法:
通常由于网络的不稳定或则数据库的bug,在使用dblink时产生了异步lock

查看是否有卡死的事务
select * from dba_2pc_pending;
Oracle 10G RAC 主机意外重启引起分布式事务故障处理

果然有两条事务卡死,stats 为 commited 说明已经提交完成了但是卡死了
清除这两条事务的方法:
1. 强制提交或回滚,上图不会成功,执行第2步
commit force ‘56.8.87893449‘;
commit force ‘104.29.28380052‘;

rollback force ‘56.8.87893449‘;
rollback force ‘104.29.28380052‘;
提交和回滚都报错:
ORA-02058: no prepared transaction found with ID 56.8.87893449

2. 在sqlplus下执行这个
SQL> execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘56.8.87893449‘);
PL/SQL procedure successfully completed.

SQL> execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘104.29.28380052‘);
PL/SQL procedure successfully completed.

--查看是否己经删除
select * from dba_2pc_pending;

select * from sys.pending_trans$
select * from sys.pending_sessions$

然后最重要的: commit
否则不同步

 


参考:
https://blog.csdn.net/csqm87956/article/details/100270329
http://blog.itpub.net/27042095/viewspace-743020/
https://docs.oracle.com/cd/B10501_01/server.920/a96521/ds_txnman.htm#9304

Oracle 10G RAC 主机意外重启引起分布式事务故障处理

上一篇:用html标签编写-数据库复习


下一篇:adb命令模拟按键事件KeyCode