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

问题描述：

河南在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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/21634752/viewspace-605153/