長事務是informix的乙個非常重要的機制，該機制如果處理不好必將非常嚴重的影響資料庫的效能和使用。其他資料庫貌似沒有類似的問題。
長事務出現的根源是乙個事務跨越的邏輯日誌檔案的數量和全部邏輯日誌檔案的數量比例控制的不好。
先說乙個事務跨越的邏輯日誌檔案的數量，該數量的大小依賴於兩個方面：
1、事務不大，但是一直沒有commit，其他事務在大量的使用邏輯日誌，當前事務跨越的邏輯日誌檔案數量就顯得很大；
2、事務確實很多，一直做不完，使用了大量的邏輯日誌，在此期間其他事務也在頻繁的使用邏輯日誌，最後該事務被判定為長事務；
為了避免長事務的出現， 所以邏輯日誌檔案的個數和大小都盡量加大。
長事務帶來的影響：
當乙個事務使用的邏輯日誌個數》=全部邏輯日誌個數*ltxhwm/100的時候，該事務就被判定為長事務，該事務開始回滾，其他事務照舊執行，沒有影響。當該事務的邏輯日誌使用個數》=全部邏輯日誌個數*ltxehwm/100的時候，資料庫就會阻塞全部的在執行的事務(除去被判定為長事務的事務照常回滾之外)。我理解資料庫之所以要阻塞其他事務的執行，是為了保障當前正在回滾的長事務必須能夠回滾完成。
一旦在其他事務被阻塞，當前長事務回滾的時候邏輯日誌被耗盡，資料庫將變的不可用。為了避免該問題的出現，需要及早給資料庫伺服器增加邏輯日誌(onparams -a -d -s -i) 。
所以控制事務的大小和增加邏輯日誌檔案的個數是解決長事務問題的王道和根本。
長事務的分類大致如下：
1、online.log中看到長事務的資訊如下：
continuing long transaction (for commit): tx 0xc0000000b28f5338 username: fisp uid: 107
事務使用邏輯日誌的數量超過了ltxhwm，該事務被server判定為長事務。但是事務已經進入了commit或rollback階段，此時資料庫伺服器允許該事務仍然使用邏輯日誌以便完成提交或回滾，而不進行強制回滾。
2、online.log中看到長事務的資訊如下：
aborting long transaction: tx 0xc0000000b8d20c18 username: fisp uid: 107
事務使用邏輯日誌的數量超過了ltxhwm，該事務被server判定為長事務。但是事務沒有進入了commit或rollback階段，此時資料庫會自動回滾該事務。
mysql長事務查詢 智庫 資料庫長事務詳解
在資料庫的日常維護中，我們常常會聽說資料庫 長事務 這個詞，那麼何為長事務？長事務是如何產生的？長事務對資料庫有什麼影響？如何防止長事務的產生？本文就根據筆者的運維經驗談談對資料庫長事務的理解。1 什麼是事務 事務是關係型資料庫中的乙個邏輯工作單元，它由乙個或多個sql語句組成，這些語句要麼全都執行...
mysql長事務的處理
1 排查業務端 1 業務是否確實需要使用長事務 比如 刪除不必要的唯讀事務。2 對使用長事務的 檢測是否有自動提交事務 可在mysql的general log中檢視是否開啟 注意 最好在業務功能測試時輸出general log，分析日誌行為提前發現問題。自動提交 setautocommit 1 檢視...
C 事務相關
之前在程式中用到事務時，都是在儲存過程中建立事務來對資料進行控制，其實在c 中也有事務類。1 dbtransaction類對資料庫訪問新增事務，它是對資料庫事務操作的基類，繼承此類的有 system.object system.marshalbyrefobject system.data.commo...