分布式事务ORA-01591错误解决

原文出处：http://www.cnblogs.com/lhrbest/archive/2016/08/04/5738544.html

【故障处理】分布式事务ORA-01591错误解决

1  BLOG文档结构图

 

 

 

2  前言部分

2.1  导读和注意事项

各位技术爱好者，看完本文后，你能够掌握以下的技能，也能够学到一些其它你所不知道的知识，~O(∩_∩)O~：

① 分布式事务的简单概念

        ② ORA-01591错误解决

  Tips：

① 本文在ITpub（http://blog.itpub.net/26736162）、博客园(http://www.cnblogs.com/lhrbest)和微信公众号（xiaomaimiaolhr）有同步更新

② 文章中用到的全部代码，相关软件，相关资料请前往小麦苗的云盘下载（http://blog.itpub.net/26736162/viewspace-1624453/）

③ 若文章代码格式有错乱，推荐使用搜狗、360或QQ浏览器，也能够下载pdf格式的文档来查看，pdf文档下载地址：http://blog.itpub.net/26736162/viewspace-1624453/，另外itpub格式显示有问题，能够去博客园地址阅读

④ 本篇BLOG中命令的输出部分须要特别关注的地方我都用灰色背景和粉红色字体来表示，好比下边的例子中，thread 1的最大归档日志号为33，thread 2的最大归档日志号为43是须要特别关注的地方；而命令通常使用×××背景和红色字体标注；对代码或代码输出部分的注释通常采用蓝色字体表示。

  List of Archived Logs in backup set 11

  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time

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

  1    32      1621589    2015-05-29 11:09:52 1625242    2015-05-29 11:15:48

  1    33      1625242    2015-05-29 11:15:48 1625293    2015-05-29 11:15:58

  2    42      1613951    2015-05-29 10:41:18 1625245    2015-05-29 11:15:49

  2    43      1625245    2015-05-29 11:15:49 1625253    2015-05-29 11:15:53

 

[ZHLHRDB1:root]:/>lsvg -o

T_XDESK_APP1_vg

rootvg

[ZHLHRDB1:root]:/>

00:27:22 SQL> alter tablespace idxtbs read write;

 

====》2097152*512/1024/1024/1024=1G 

 

本文若有错误或不完善的地方请你们多多指正，ITPUB留言或QQ皆可，您的批评指正是我写做的最大动力。

 

 

3  故障分析及解决过程

 

3.1  故障环境介绍

 

项目	source db
db 类型	RAC
db version	11.2.0.3
db 存储	ASM
OS版本及kernel版本	AIX 64位 6.1.0.0

 

3.2  故障发生现象及报错信息

有同事发来错误：

 

 

执行一个update语句的时候报错ORA-01591的错误。

 

3.3  故障分析及解决过程

这个错误是因为分布式事务引发，而不是普通的锁引发的，检查通常对象数据表锁定，只须要检查v$locked_object和v$transaction视图，就能够定位到具体的SQL语句和操做人等信息，可是检查以后的结果以下：

SYS@oraLHR12>  select * from gv$locked_object;

 

no rows selected

 

SYS@oraLHR12> select * from gv$transaction;

 

no rows selected

两个关键视图中，没有锁定的对象，也没有正在进行没有提交的事务。那是否是没有锁定呢？或者锁已经释放了，咱们尝试对数据表加锁：

SYS@oraLHR12> select * from LHR.LHRBOKBAL for update;

select * from LHR.LHRBOKBAL for update

                   *

ERROR at line 1:

ORA-01591: lock held by in-doubt distributed transaction 20.13.14721

 

SYS@oraLHR12> select count(1) from LHR.LHRBOKBAL;

 

  COUNT(1)

----------

  30998411

 

 

系统没有像通常阻塞那样等待，而是报错ORA-01591的错误，而且提示锁被一个分布式事务持有，不能实现加锁操做,那么ORA-01591错误到底是什么呢？咱们使用oerr工具查看该错误编号，看看有没有值得关注的信息。

root@ZFLHRRSP:/# oerr ora 1591

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.

简单的说，01591错误的缘由是该对象被一个处在“in-doubt”状态的分布式事务锁定。分布式事务使用的是“two-phase commit”二阶段提交技术。解决该问题的方法就是查看内部表pending_trans$，肯定分布式事务信息。这种状态的事务主要是因为在进行分布式事务时候，发生网络突发中断的状况，引发分布式事务没法正常结束，等待中断节点的事务响应。因而，各节点的事务所锁定的表就不会被释放掉。

此时，咱们检查视图DBA_2PC_PENDING（或者基表pending_trans$），查看是否存在这种状况。

 

果真，当前存在一个阻塞分布式事务，处在prepared状态。当前问题，主要是源于在进入prepared阶段以后，发生了网络中断的现象，引发commit的阶段不能等待到事务信息。因此，才会一直处在Prepared状态，数据表也就不会进行释放。

对于这个事务，只能经过链接网络或者强制提交回退事务来结束。咱们可使用commit force或者rollback force来进行处理，这里咱们进行回滚操做：

SYS@oraLHR12> rollback force '20.13.14721';

 

Rollback complete.

 

SYS@oraLHR12>

Rollback force的参数是DBA_2PC_PENDING中记录本地事务信息的编号即LOCAL_TRAN_ID。

 

此时，再次查看数据。

 

此时，该事务状态已经变化为forced rollback表示已经强制回退,咱们再次尝试锁定表操做：

16:25:31 SQL> select CURRENCY from tpcc.TPCCBOKBAL WHERE ROWNUM=1  for update;

CURRENCY

--------

001

Executed in 0.025 seconds

能够看出已经不报错了，能够正常执行。

4  分布式事务相关知识点

分布式事务，简单来讲，是指一个事务在本地和远程执行，本地须要等待确认远程的事务结束后，进行下一步本地的操做。如经过dblink update远程数据库的一行记录，若是在执行过程当中网络异常，或者其余事件致使本地数据库没法得知远程数据库的执行状况，此时就会发生in doublt的报错。此时须要dba介入，且须要分多种状况进行处理。

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恢复自动解决分布事务。

 

5  两个重要的视图

5.1  DBA_2PC_PENDING

DBA_2PC_PENDING:列出全部的悬而未决的事务﹐此视图在末填入悬而未决的事务以前是空的﹐解决这后也被清空。

列名	说明
LOCAL_TRAN_ID	本地事务标识﹐格式为integer.integer.ingeger。 当一个链接的local_tran_id和global_tran_id相同时﹐那么该节点是该事务的全局协调器。
GLOBAL_TRAN_ID	全局事务标识,格式为﹕global_db_name.db_hex_id.local_tran_id,其中db_hex_id是用来标识数据库八字符的十六进制数﹐公共事各id在分布式事务的每一个节点都是相同的。
STATE	下图表进行说明
MIXED	“YES”意味着一部分事务已经在一个节点上提交﹐而在另外一个节点上被回滚。
TRAN_COMMENT	事务的注释﹐或者若是使用了事务命名﹐当事各被提交时﹐事务的名字就会出如今此处
Host	主机名
Commit#	已提交的事务的全局提交数

 

DBA_2PC_PENDING的STATE列的说明

列值	说明
Connecting	一般状况下﹐只有全局协调器和本地协调器才使用这个条目﹐节点在可以决定它是否可以准备好以前﹐要收集来自于其它数据库服务的信息。
Prepared	节点已准好﹐可能或者也可能没有将已准备好的消息通知本地协调器﹐但此时﹐该节点尚未接收到提交的请求﹐仍保持着准许备好的状态﹐控制着提交事务所必需的任何本地资源。
Commited	节点(任何类型)已经提交了事务﹐但该事务所包含的其它节点可能并无提交﹐也就是该事务在一个个或多个其它节点上仍然是悬而未决 。
Forced commit	DBA进行判断后﹐能够强行提交未决的事务﹐若是一个事务由DBA在本地节点进行手动提交时﹐产生此项目
Forced abor(rollback)	DBA进行判断后﹐能够强行回滚未决的事务﹐若是一个事务由DBA在本地节点进行手动回滚时﹐产生此项目

 

SELECT * FROM DBA_2PC_PENDING;

 

 

5.2  DBA_2PC_NEIGHBORS

DBA_2PC_NEIGHBORS:列出全部得到的(从远程客户)和送出的(给远程服务器)悬而未决的事务﹐也表示该本地节点是否是事务的提交点站点。

列名	说明
LOCAL_TRAN_ID	同上
IN_OUT	得到事务为IN﹐送出事务为OUT
Database	对得到事务来讲指本地节点信息的客户数据库的名称﹔对送出的事务来讲指用于访问远程服务器上信息的数据库连接的名称
DBuser_owner	对得到事务来讲指远程数据库连接用于链接的本地帐户﹔对于送出事务来讲指该数据库连接的拥有者。
INTERFACE	‘C’表明提交信息﹐’N’表示已准备好状态的一条消息或是一条请求只读提交的请求。 当’IN_OUT’为OUT时﹐’C’表示该链接的远程的站点是提交点站点,而且知道是提交仍是中断。’N’表示本地节点正在通知远程节点﹐说它已准备好。 当’IN_OUT’为IN时﹐‘C’表示本地节点或送出的远程的一个数据库是提交点站点﹐’N’表示本地节点正在通知远程节点﹐说它已准备好

 About Me

..........................................................................................................................................................................................................                        

v 本文做者：小麦苗，只专一于数据库的技术，更注重技术的运用

v 本文在ITpub（http://blog.itpub.net/26736162）、博客园(http://www.cnblogs.com/lhrbest)和我的微信公众号（xiaomaimiaolhr）上有同步更新，推荐pdf文件阅读或博客园地址阅读

v QQ群：230161599 微信群：私聊

v 本文itpub地址： http://blog.itpub.net/26736162/viewspace-2122999/   博客园地址：http://www.cnblogs.com/lhrbest/p/5738544.html

v 本文pdf版：http://yunpan.cn/cdEQedhCs2kFz （提取码：ed9b）

v 小麦苗分享的其它资料：http://blog.itpub.net/26736162/viewspace-1624453/

v 联系我请加QQ好友(642808185)，注明添加原因

v 于 2016-08-02 09:00~2016-08-03 19:00 在中行完成

v 【版权全部，文章容许转载，但须以连接方式注明源地址，不然追究法律责任】

..........................................................................................................................................................................................................

原文出处：http://www.cnblogs.com/lhrbest/archive/2016/08/04/5738544.html