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


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

 BLOG文档结构图

wps4048.tmp 

 

 

 前言部分

2.1  导读和注意事项

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

① 分布式事务的简单概念

        ② ORA-01591错误解决

  Tips:

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

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

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

④ 本篇BLOG中命令的输出部分需要特别关注的地方我都用灰色背景和粉红色字体来表示,比如下边的例子中,thread 1的最大归档日志号为33thread 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.1  故障环境介绍

 

项目

source db

db 类型

RAC

db version

11.2.0.3

db 存储

ASM

OS版本及kernel版本

AIX 64位 6.1.0.0

 

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

有同事发来错误:

wps4049.tmp 

wps405A.tmp 

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

 

3.3  故障分析及解决过程

这个错误是由于分布式事务引起,而不是普通的锁引起的,检查一般对象数据表锁定,只需要检查v$locked_objectv$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

 

wps405B.tmp 

系统没有像一般阻塞那样等待,而是报错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$),查看是否存在这种情况。

wps405C.tmp 

果然,当前存在一个阻塞分布式事务,处在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

 

此时,再次查看数据。

wps406C.tmp 

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

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

CURRENCY

--------

001

Executed in 0.025 seconds

可以看出已经不报错了,可以正常执行。

 分布式事务相关知识点

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

Oracle会自动处理分布事务,保证分布事务的一致性,所有站点全部提交或全部回滚。一般情况下,处理过程在很短的时间内完成,根本无法察觉到。

但是,如果在commitrollback的时候,出现了连接中断或某个数据库 站点CRASH的情况,则提交操作可能会无法继续,此时DBA_2PC_PENDINGDBA_2PC_NEIGHBORS中会包含尚未解决的分布事务。 对于绝大多数情况,当恢复连接或CRASH的数据库重新启动后,会自动解决分布式事务,不需要人工干预。只有分布事务锁住的对象急需被访问,锁住的回滚段阻止了其他事务的使用,网络故障或CRASH的数据库的恢复需要很长的时间等情况出现时,才使用人工操作的方式来维护分布式事务。 手工强制提交或回滚将失去二层提交的特性,Oracle无法继续保证事务的一致性,事务的一致性应由手工操作者保证

使用ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY,可以使Oracle不再自动解决分布事务,即使网络恢复连接或者CRASH的数据库重新启动。

ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY恢复自动解决分布事务。

 

 两个重要的视图

5.1  DBA_2PC_PENDING

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

列名

说明

LOCAL_TRAN_ID

本地事务标识﹐格式为integer.integer.ingeger

当一个连接的local_tran_idglobal_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;

wps406D.tmp 

 

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 本文在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 【版权所有,文章允许转载,但须以链接方式注明源地址,否则追究法律责任】

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

长按识别二维码或微信客户端扫描下边的二维码来关注小麦苗的微信公众号:xiaomaimiaolhr,学习最实用的数据库技术。

wps407E.tmp

 

 

 


本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
我们有几个项目使用了Windows Server 2008+ ROSE HA+Oracle 的组合方案,但是最近遇到了一个不大不小的麻烦。 甲方在进行故障测试时,断掉了一个网络交换机 的电源 (共有两个网络交换机,对应两个冗余的业务网络),Oracle服务竟然停止了,导致所有的客户端数据库连接中断。 首先,这个测试结果甲方是无法接受的; 其次,这个结果也出乎我们的意料,在另外一个交换机正常工作的情况下,ROSE HA 停止了 Oracle服务。 那么,如何给甲方一个交代呢?在和 ROSE售后经过多次沟通后,
故障现象: 用服务器上面的(客户端)sql server management  stutio 去连接本服务器上的sql server 数据库,如下图:点击连接不报任何错,就是连接不上,一直处于等待状态; 但是通过windows 身份验证是可以连接的,并且是可以正常操作的,如下图:服务器名字不在是个IP,要选择local. 通过这个现象可判断出 数据库本身的服务(通过任务管理器中也可以看出来)是没有问题,只是连接方面出现问题:网络,端口或者是监听之类的问题。 这是网上查到的一篇文档:经验证我的这里是 没有
《 Oracle DBA 工作笔记》第二章 常用工具和问题分析   一.1    BLOG 文档结构图     一.2    本文简介 建荣的新书《 Oracle DBA 工作笔记》第二章的目录如下图,主要讲解了 SQL*Plus 、 exp/imp 、 expdp/impdp 以及常见的问题分析,第二章的目录如下:     下边小麦苗将自己阅读完第二章后整理的一些内容分享给大家。 一.3    第一章内容修改 一.3.1    删除数据库的几种方式 这个内容是第一章( http://blog.itpub
工作中可能需要某一天各个时间段的ash报告或awr报告,手动一个一个生成太费力了.利用 dbms_workload_repository 包再配合sqlplus的spool 可以使这件事情简单一些. 以下示例: 一.批量生成一天的ash报告 1.生成查询语句 #此处是按照15分钟的间隔时间,生成前一天所有的ash报告  的查询语句 select 'spool ash_'||db_unique_name||'_'||inst_id||'_'||to_char(trunc(sysdate-1)+level/9
分区索引分为本地索引和全局索引,但对于在分区表上建索引,一般用的比较多的还是普通索引和本地分区索引,而全局分区索引相对用的比较少. 以下测试为验证:分区表上 的本地分区索引 因为查询条件引起跨分区,是否改为普通索引更合适. 以下测试: oracle version:11.2.0.4 建测试表: drop table SCOTT.TB_TEST01; create table SCOTT.TB_TEST01 partition by range (CREATED) (   partition P_2015
关于半自动化搭建Data Guard,自己花了一些时间,总算是把这件事情继续推进了一下,还是再啰嗦一句,为什么不自动化,因为安全。主库就是主库,任何变更都要手工检查审核,自动化的工作在备库和中控端来完成。我希望自己的脚本能够只知道主库的IP,不用一次又一次连过去配置和检查,当然要完成自动化还是半自动化,有些网友也提醒的极是,那就是规范和标准。 预先条件: 1.目前的设计是基于11.2.0.4的版本,当然这个很容易定制,在此是作为一个基本的标准,作为环境的初始化和Data Guard对的搭建的基线。 2.默认
   前段时间有个开发的同事向我咨询一个问题,     开发同事:Oracle会存在一个用户插入数据,已经提交了;但是另外一个用户还查询不到吗?都是同一张表     jeanron:   不会的。     开发同事: 我们现在一个用户写入,程序日志是说已经写入;可是读取的用户还读取不到,在线延迟5分钟可能的问题在哪儿?或者你帮忙监控一下?     jeanron:   是Oracle吗,MySQL还可能有这种情况     开发同事: Oracle,MySQL是什么情况下会这样?     jeanron: 
【故障处理】 ORA-19809 错误处理 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ① ORA-19809: limit exceeded for recovery files 错误的处理方法 RMAN-03009: failure of backup command on ORA_DISK_1 channel at 07/26/2016 17

手工搭建Data Guard - 2016-08-03 17:08:05

Data Guard的搭建可以使用GC图形化安装,优缺点很明显,优点就是图形化操作,符合国人的习惯(据secooler介绍外国程序员能用图形化做的事就一定用图形做,因为boss看得懂,和国人正相反。。。),缺点就是如同Windows一样,宛如黑盒,换句话说,要时刻祈祷不要出问题,否则有时很难知道他为什么挂了。。。 Data Guard还可以使用命令行操作,正如各位所知,图形化的任何操作背后,其实都是使用的命令。OCM第七场景考试中,我也是纠结了许久,临开始前才决定使用手工方式创建DG,怕的就是图形安装的不

mysql分区技术测试 - 2016-07-25 19:07:38

mysql是否支持partition呢,在mysql下执行show plugins;(显示插件) 其中包含了partition字段就说明你的数据库支持分区技术 1,创建带有分区的表 表明创建了带有hash分区技术的表,t2表有5个分区 mysql支持的几种分区技术,最常用的是range和list二种,Hash主要用来测试 看到test中有12张t2表,每个分区表都有表索引,检索数据更快。 把t2表创建索引 create index in_id on t2(id); 2、现在我们插入一个一千万行的数据来测试