問題描述：

河南在2009年4月28日早09：23出現柜面交易如CDM，FIX，CARDTLR等服務堵塞，且排隊不斷增加，后通過down掉FIX、CARDTLR服務后使資源得到釋放，在事后的分析中，我們發(fā)現在出現異常堵塞時，產生了tuxedo和數據庫通訊異常的日志，xa_NULL02232009.trc，查看日志內出現問題的pid,發(fā)現均為綠卡通的相關服務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$

很多上面的類似日志，發(fā)現undo 日志的創(chuàng)建和切換的日志

切換unto tablespace ，也就是新建一個臨時undo tablespace，切換一下，待處理完畢后切換回來

分析：

數據庫本身會根據事務的量，自己調節(jié)創(chuàng)建和回收UNDo 數據段，undo 日志不斷的創(chuàng)建和切換的過程是因為短時間事務極速的上升，并且這是事務的處理存在大量需要事務回滾，數據的回滾造成事務的處理時間減慢，TUXEDO的處理等待時間變長，導致會話事務超時前(Session timeout (SesTm))就會觸發(fā)了Global transaction timeout (全局事務超時)，就會發(fā)生上面的錯誤：

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,則觸發(fā)超時；

對DB2而言，如果T-T1-T2 > T3 > SESTM2,則觸發(fā)超時；

由此可以看出，此參數的主要目的是對數據庫進行資源保護，避免在全局交易中，已經完成任務的數據庫，為等待其他參與方耗費過多的資源，畢竟ORACLE中并發(fā)全局交易的數量是很有限的。

2.14.6 超時后果

觸發(fā)此超時后，數據庫將自己主動回滾已經完成的任務，釋放全局交易資源。TUXEDO控制的全局交易進行TPCOMMIT時，如果總時間仍沒有超過Transaction TimeOut，那么TPCOMMIT將失敗，XALOG會記錄下ORACLE錯誤："ORA-24756: Transaction does not exist"。確實如此，拿上面的例子來說，等到最后TPCOMMIT的時候，DB1已經主動回滾了所有的數據，不難理解，對DB1而言，它好像根本沒有參加過這個全局交易，自然就會有這樣的錯誤提示。

2.14.7 設置考慮

這個參數是從數據庫自我保護的角度設計的，對數據庫而言，是不得已的辦法。最好的措施還是TUXEDO能夠控制時間，趕在SESTM之前，進行TPABORT，主動通知數據庫進行數據回滾。

用一個簡單的比方：冬天，客人出門時沒有關門，SESTM時間后，客人還沒有回來，主人感覺到冷了，只好自己去關門，不管什么理由，這樣總是不太好。如果在SESTM時間內，客人能及時回來關門，主人就不會感覺那么差。

從前面的超時觸發(fā)分析，我們也能發(fā)現，只要設置SESTM 能夠大于 TransactionTimeOut的話，就能夠盡量的不觸發(fā)此超時機制，達到較好的效果。

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時間后，如果第一分布式事務仍然沒有釋放此資源，第二個事務觸發(fā)此超時。

2.17.6 超時后果

如果資源被第一個事務正常使用鎖定，ORACLE回滾第二個事務，并返回錯誤："ORA-02049: time-out: distributed transaction waiting for lock "。

如果第一個事務處理完成，資源釋放后，再嘗試第二個事務，就會成功。如果第二個事務不能等待資源自動釋放，那么可以采用處理數據庫死鎖(deadlock)的措施，人工介入，清除第一個事務，但一般不建議采用這種方式，因為第一個事務一般會正常結束的。

如果資源被第一個事務因為處于不確定分布事務狀態(tài)(in-doubt distributed transaction)而鎖定，ORACLE回滾第二個事務，并返回錯誤："ORA-01591: lock held by in-doubt distributed transaction identifier "。

這種錯誤遇到的可能性較小，一般只有在分布事務的關鍵提交階段出現網絡、系統(tǒng)故障，才可能出現此故障，而且，當網絡、系統(tǒng)故障恢復后，ORACLE一般可以自己解決此問題，不需要人工介入。如果一定要人工介入，可以查閱ORACLE專門的手冊。

2.17.7 設置考慮

出現這樣的超時，是因為特定數據庫資源的使用碰撞，要分析應用系統(tǒng)的業(yè)務特點，確定碰撞可能發(fā)生的條件，在此條件下，資源可能被先來者鎖定多長時間(T1)，后來者又能夠等多長時間(T2)，再來設置此參數(T)的大小。如果在大多數情況下，T1 < T2, 那么就設置T1 < T < T2；反之，大多數情況下，T1 > T2，那么，就設置T < T2。

因此，不分析業(yè)務特點，一味的增大和減小是不恰當的。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Relevant parameters: WSL中可以配置的－T(客戶端idle時間)、－I(client init時間)參數

另外配置RESOURCE section的BLOCKTIME、SCANUNIT

總結

以上是生活随笔為你收集整理的查oracle事务超时时间,ORA-24756: 事务处理不存在 分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。