ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORA-24756: 事务处理不存在 分析

ORA-24756: 事务处理不存在 分析

原创 Linux操作系统 作者:wuft2003 时间:2009-06-04 22:58:39 0 删除 编辑

问题描述:

河南在2009年4月28日早09:23出现柜面交易如CDM,FIX,CARDTLR等服务堵塞,且排队不断增加,后通过down掉FIX、CARDTLR服务后使资源得到释放,在事后的分析中,我们发现在出现异常堵塞时,产生了tuxedo和数据库通讯异常的日志,xa_NULL02232009.trc,查看日志内出现问题的pid,发现均为绿卡通的相关服务id

日志内容是多个:

092345.4210884.0:
xaostart: XAER_NOTA; RESUME|JOIN and can't switch txn

ORACLE XA: Version 9.2.0.1.0. RM name = 'Oracle_XA'.


092438.3817644.0:
ORA-24756: 事务处理不存在

分析:

查看数据库alert_*.log (back)日志:

ue Apr 28 09:28:24 2009
Undo Segment 35 Onlined
Tue Apr 28 09:28:24 2009
Undo Segment 36 Onlined
Tue Apr 28 09:28:24 2009
Undo Segment 37 Onlined


Tue Apr 28 09:28:25 2009
Created Undo Segment _SYSSMU60$
Tue Apr 28 09:28:25 2009
Created Undo Segment _SYSSMU61$
Tue Apr 28 09:28:25 2009
Created Undo Segment _SYSSMU62$

很多上面的类似日志,发现undo 日志的创建和切换的日志

切换unto tablespace ,也就是新建一个临时undo tablespace,切换一下,待处理完毕后切换回来

分析:

数据库本身会根据事务的量,自己调节创建和回收UNDo 数据段,undo 日志不断的创建和切换的过程是因为短时间事务极速的上升,并且这是事务的处理存在大量需要事务回滚,数据的回滚造成事务的处理时间减慢,TUXEDO的处理等待时间变长,导致会话事务超时前(Session timeout (SesTm))就会触发了Global transaction timeout (全局事务超时),就会发生上面的错误:

ORA-24756: 事务处理不存在

结论:

相关的数据库参数:
     1. Global transaction timeout   
     2. Session timeout (SesTm)   
     3. Oracle distributed_lock_timeout 

  要求:  Global transaction timeout  《  Session timeout (SesTm)   《  Oracle distributed_lock_timeout

 

事务的超时时间基本与上面三个时间有关,在设置超时时间的时候一般要遵从上面的原则。

参考资料:

2.14 ORACLE XA OPENINFO参数:SESTM
2.14.1 参数出处
  UBBCONFIG配置文件 -> GROUPS -> OPENINFO ->SESTM 。
2.14.2 时间单位
  秒。
2.14.3 取值范围
  大于等于0,0表示无限时长。
2.14.4 默认取值
  无,使用时必须明确设置 。
2.14.5 用途解释
  会话静默等待时长,即全局交易中,作为资源管理器(resource manager)已经参与交易并完成相应的数据操作的数据库,等待全局交易中的其他参与方操作完成的时间长度。
  举例说明:
  假设一个全局交易由以下几个部分组成:
  (1)tpbegin(T,0) ->
  (2)tpcall(S1) -> DB1 完成耗时 T1;
  (3)tpcall(S2) -> DB2 完成耗时 T2;
  (4)其他操作 耗时 T3
  (5)tpcommit()
  其中,tpcall(S1)访问数据库DB1, tpcall(S2)访问数据库DB2。
  对DB1而言,如果T-T1> T2+T3 > SESTM1,则触发超时;
  对DB2而言,如果T-T1-T2 > T3 > SESTM2,则触发超时;
  由此可以看出,此参数的主要目的是对数据库进行资源保护,避免在全局交易中,已经完成任务的数据库,为等待其他参与方耗费过多的资源,毕竟ORACLE中并发全局交易的数量是很有限的。
2.14.6 超时后果
  触发此超时后,数据库将自己主动回滚已经完成的任务,释放全局交易资源。TUXEDO控制的全局交易进行TPCOMMIT时,如果总时间仍没有超过Transaction TimeOut,那么TPCOMMIT将失败,XALOG会记录下ORACLE错误:"ORA-24756: Transaction does not exist"。确实如此,拿上面的例子来说,等到最后TPCOMMIT的时候,DB1已经主动回滚了所有的数据,不难理解,对DB1而言,它好像根本没有参加过这个全局交易,自然就会有这样的错误提示。
2.14.7 设置考虑
  这个参数是从数据库自我保护的角度设计的,对数据库而言,是不得已的办法。最好的措施还是TUXEDO能够控制时间,赶在SESTM之前,进行TPABORT,主动通知数据库进行数据回滚。
  用一个简单的比方:冬天,客人出门时没有关门,SESTM时间后,客人还没有回来,主人感觉到冷了,只好自己去关门,不管什么理由,这样总是不太好。如果在SESTM时间内,客人能及时回来关门,主人就不会感觉那么差。
  从前面的超时触发分析,我们也能发现,只要设置SESTM 能够大于 TransactionTimeOut的话,就能够尽量的不触发此超时机制,达到较好的效果。

 


2.17 ORACLE distributed_lock_timeout
2.17.1 参数出处
  ORACLE初始参数文件:init.ora -> distributed_lock_timeout。
2.17.2 时间单位
  秒。
2.17.3 取值范围
  大于0。
2.17.4 默认取值
  60 。
2.17.5 用途解释
  分布式事务锁等待超时(distributed transaction waiting for lock),指第二个事务处理需要的数据库资源,正被第一个分布式事务占用而锁定,那么,第二个事务将等待第一个分布式事务释放此资源,等待distributed_lock_timeout时间后,如果第一分布式事务仍然没有释放此资源,第二个事务触发此超时。
2.17.6 超时后果
  如果资源被第一个事务正常使用锁定,ORACLE回滚第二个事务,并返回错误:"ORA-02049: time-out: distributed transaction waiting for lock "。
  如果第一个事务处理完成,资源释放后,再尝试第二个事务,就会成功。如果第二个事务不能等待资源自动释放,那么可以采用处理数据库死锁(deadlock)的措施,人工介入,清除第一个事务,但一般不建议采用这种方式,因为第一个事务一般会正常结束的。
  如果资源被第一个事务因为处于不确定分布事务状态(in-doubt distributed transaction)而锁定,ORACLE回滚第二个事务,并返回错误:"ORA-01591: lock held by in-doubt distributed transaction identifier "。
  这种错误遇到的可能性较小,一般只有在分布事务的关键提交阶段出现网络、系统故障,才可能出现此故障,而且,当网络、系统故障恢复后,ORACLE一般可以自己解决此问题,不需要人工介入。如果一定要人工介入,可以查阅ORACLE专门的手册。
2.17.7 设置考虑
  出现这样的超时,是因为特定数据库资源的使用碰撞,要分析应用系统的业务特点,确定碰撞可能发生的条件,在此条件下,资源可能被先来者锁定多长时间(T1),后来者又能够等多长时间(T2),再来设置此参数(T)的大小。如果在大多数情况下,T1 < T2, 那么就设置T1 < T < T2;反之,大多数情况下,T1 > T2,那么,就设置T < T2。
  因此,不分析业务特点,一味的增大和减小是不恰当的。


====================================================
Relevant parameters: WSL中可以配置的-T(客户端idle时间)、-I(client init时间)参数
另外配置RESOURCE section的BLOCKTIME、SCANUNIT

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/21634752/viewspace-605153/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-05-12

  • 博文量
    295
  • 访问量
    322837