查oracle事务超时时间,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
總結
以上是生活随笔為你收集整理的查oracle事务超时时间,ORA-24756: 事务处理不存在 分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： phpcms 加载php文件,PHPCM
- 下一篇： oracle需求分析,8-oracle_