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