問題描述：
河南在2023年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
事務的超時時間基本與上面三個時間有關，在設定超時時間的時候一般要遵從上面的原則。
PB事務處理
1 資料視窗更新，只要dberror有錯誤，而事先沒有做過任何commit工作，那麼rollback可以回滾到上次commit位置，即上次commit後所有的資料將被回滾。2 如果是直接寫入sql語句，只要資料庫出現錯誤，那麼rollback可以回滾到上次commit的位置，即上次commit後所有...
MySQL事務處理
start transaction,commit和rollback語法 start transaction begin work commit work and no chain no release rollback work and no chain no release set autocom...
ASP事務處理
asp事務處理。測試資料庫為sql server，伺服器為本機，資料庫名為test，表名為a，兩個欄位id int 主鍵標識,num int set conn server.createobject adodb.connection strconn provider sqloledb.1 persi...