当前位置:Gxlcms > mysql > ORA-01591错误解决方法

ORA-01591错误解决方法

时间:2021-07-01 10:21:17 帮助过:25人阅读

在遇到ORA错误时,我们不可能知道每个ORA错误都是什么意思,所以通过oracle的联机文档查错误的cause和action可以让我们初步了解该

摘要:

在访问某些表的特定行时报ORA-01591错误

select * from BF_INCOME_EXPENSES_T

where account_id = 36816153

and user_id = 39964213

and city_code = '185'

ORA-01591: 锁定已被有问题的分配事务处理72.0.1608712挂起

SQL> select count(*) from UNITELE.BI_MQSYNC_SOURCE_CONTROL_T1;

ORA-01591: 锁定已被有问题的分配事务处理72.0.1608712挂起

由于该表是业务关键表,部分前台业务受到影响。

关键词:ORA-01591 DBA_2PC_PENDING 分布式事务

1.故障分析

首先,在遇到ORA错误时,我们不可能知道每个ORA错误都是什么意思,所以通过Oracle的联机文档查错误的cause和action可以让我们初步了解该错误。

01591, 00000, "lock held by in-doubt distributed transaction %s"

// *Cause:Trying to access resource that is locked by a dead two-phase commit

//transaction that is in prepared state.

// *Action: DBA 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, DBA should contact DBA at commit

//point if known or 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.


Oracle对ORA-01591错误的描述是"lock held by in-doubt distributed transaction %s,由分布式事务持有锁造成的。通过错误的cause可以看到’Trying to access resource that is locked by a dead two-phase commit transaction that is in prepared state’该错误是由访问一个处于prepared状态的二阶段事务所持有锁的资源造成的。

下面简单介绍一下分布式事务。

分布式事务,简单来说,是指一个事务在本地和远程执行,本地需要等待确认远程的事务结束后,进行下一步本地的操作。如通过dblink update远程数据库的一行记录,如果在执行过程中网络异常,或者其他事件导致本地数据库无法得知远程数据库的执行情况,此时就会发生in doublt的报错。此时需要dba介入,且需要分多种情况进行处理。

分布式事务的Two-Phase Commit机制,会经历3个阶段:

1.PREPARE PHASE:

1.1 决定哪个数据库为commit point site。(注,参数文件中commit_point_strength值高的那个数据库为commit point site)

1.2 全局协调者(Global Coordinator)要求所有的点(除commit point site外)做好commit或者rollback的准备。此时,对分布式事务的表加锁。

1.3 所有分布式事务的节点将它的scn告知全局协调者。

1.4 全局协调者取各个点的最大的scn作为分布式事务的scn。

至此,所有的点都完成了准备工作,我们开始进入COMMIT PHASE阶段,此时除commit point site点外所有点的事务均为in doubt状态,直到COMMIT PHASE阶段结束。

2.COMMIT PHASE:
2.1 Global Coordinator将最大scn传到commit point site,要求其commit。
2.2 commit point尝试commit或者rollback。分布式事务锁释放。
2.3 commit point通知Global Coordinator已经commit。
2.4 Global Coordinator通知分布式事务的所有点进行commit。

3.FORGET PHASE:
3.1 参与的点通知commit point site他们已经完成commit,commit point site就能忘记(forget)这个事务。
3.2 commit point site在远程数据库上清除分布式事务信息。
3.3 commit point site通知Global Coordinator可以清除本地的分布式事务信息。
3.4 Global Coordinator清除分布式事务信息。

有关分布式事务的详细信息请参阅oracle联机文档.

当前的分布式事务处于Two-Phase Commit机制中的prepared阶段,这个阶段事务已经在表上加锁了,现在我们要访问这些表,但事务没有结束,一直持有锁,导致访问资源失败报ORA-01591。(在这里需要指出:分布式事务所持有的锁之所以堵塞读操作,是因为oralce不知道该显示哪个版本的数据) 如果结束这个事务,那相应的锁也会释放,这样就能解决这个问题。我们知道要结束一个事务有两种办法:commit和rollback。现在我们尝试结束这个事务:

commit force '72.0.1608712';

ORA-02058: no prepared transaction found with ID 72.0.1608712


报错并没有发现prepared状态的事务,由于该事务是分布式事务,我们首先想到的是dba_2pc_pending这个试图


SQL> select * from dba_2pc_pending;

no rows selected

该试图并没有查到信息,所以我们无法用commit force结束这个分布式事务,那么现在我们查看是否存在该事务,通过实际报错,我们可以清晰的看到事务号为72.0.1608712,该事务在72号回滚段的0号事务槽上并且序列号是1608712,这时查询一个基表x$ktuxe,看看72号回滚段上是否有该事务。

SQL> SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */

2 KTUXESTA Status,

3KTUXECFL Flags

4FROM x$ktuxe

5WHERE ktuxesta!='INACTIVE'

6 AND ktuxeusn= 72;


KTUXEUSNKTUXESLTKTUXESQN STATUSFLAGS

---------- ---------- ---------- ---------------- ------------------------

7201608712 PREPAREDSCO|COL|REV|DEAD

通过x$ktuxe这个基表,我们看到确实存在这个事务,而且是prepared状态。

人气教程排行