問題描述：

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

日志內(nèi)容是多個：

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: 事務(wù)處理不存在

分析：

查看數(shù)據(jù)庫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ā)現(xiàn)undo 日志的創(chuàng)建和切換的日志

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

分析：

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

ORA-24756: 事務(wù)處理不存在

結(jié)論：

相關(guān)的數(shù)據(jù)庫參數(shù)：

1. Global transaction timeout

2. Session timeout (SesTm)

3. Oracle distributed_lock_timeout

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

事務(wù)的超時時間基本與上面三個時間有關(guān)，在設(shè)置超時時間的時候一般要遵從上面的原則。

參考資料：

2.14 ORACLE XA OPENINFO參數(shù)：SESTM

2.14.1 參數(shù)出處

UBBCONFIG配置文件 -> GROUPS -> OPENINFO ->SESTM 。

2.14.2 時間單位

秒。

2.14.3 取值范圍

大于等于0，0表示無限時長。

2.14.4 默認(rèn)取值

無，使用時必須明確設(shè)置 。

2.14.5 用途解釋

會話靜默等待時長，即全局交易中，作為資源管理器(resource manager)已經(jīng)參與交易并完成相應(yīng)的數(shù)據(jù)操作的數(shù)據(jù)庫，等待全局交易中的其他參與方操作完成的時間長度。

舉例說明：

假設(shè)一個全局交易由以下幾個部分組成：

(1)tpbegin(T,0) ->

(2)tpcall(S1) -> DB1 完成耗時 T1;

(3)tpcall(S2) -> DB2 完成耗時 T2;

(4)其他操作 耗時 T3

(5)tpcommit()

其中，tpcall(S1)訪問數(shù)據(jù)庫DB1, tpcall(S2)訪問數(shù)據(jù)庫DB2。

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

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

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

2.14.6 超時后果

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

2.14.7 設(shè)置考慮

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

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

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

2.17 ORACLE distributed_lock_timeout

2.17.1 參數(shù)出處

ORACLE初始參數(shù)文件：init.ora -> distributed_lock_timeout。

2.17.2 時間單位

秒。

2.17.3 取值范圍

大于0。

2.17.4 默認(rèn)取值

60 。

2.17.5 用途解釋

分布式事務(wù)鎖等待超時(distributed transaction waiting for lock)，指第二個事務(wù)處理需要的數(shù)據(jù)庫資源，正被第一個分布式事務(wù)占用而鎖定，那么，第二個事務(wù)將等待第一個分布式事務(wù)釋放此資源，等待distributed_lock_timeout時間后，如果第一分布式事務(wù)仍然沒有釋放此資源，第二個事務(wù)觸發(fā)此超時。

2.17.6 超時后果

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

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

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

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

2.17.7 設(shè)置考慮

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

因此，不分析業(yè)務(wù)特點，一味的增大和減小是不恰當(dāng)?shù)摹?/p>

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

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

另外配置RESOURCE section的BLOCKTIME、SCANUNIT

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。