一、查看數據庫狀態
正常情況下是
onstat -
IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line -- Up 35 days 16:51:16 -- 3920896 Kbytes
長事務情況下是
onstat -
IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line (LONGTX) -- Up 35 days 16:41:40 -- 3920896 Kbytes
Blocked:LONGTX
二、顯示事務（transaction）信息
其中flag字段中第三個標誌位爲R說明事務在rollback，說明這個事務是長事務
onstat -x
IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line (LONGTX) -- Up 35 days 16:41:56 -- 3920896 Kbytes
Blocked:LONGTX
Transactions
address flags userthread locks begin_logpos current logpos isol rb_time retrys coord
1cf0a6748 A-R-- 1cd55c618 642073 119403 119405 0x1aa91e4 DIRTY 0
三、通過長事務的userthread值找出session id
onstat -u |grep 1cd55c618
address flags sessid user tty wait tout locks nreads nwrites
1cd55c618 --RPX-- 1880841 informix - 0 0 642073 256446 323049
四、顯示會話連接信息，找出造成長事務的SQL語句，並優化
onstat -g ses 1880841
什麼是“長事務”?
Informix 長事務 (Long Transaction) 詳解
要理解什麼是“長事務”，還要從“事務”本身及數據庫的邏輯日誌工作原理談起。所謂“事務”(transaction)，是一個完整的不可分割的數據處理單元。該單元中所有的數據處理操作要麼全部處理成功，要麼因其中任意一個操作的失敗而完全回滾至整個事務處理前狀態。爲了保證事務的完整性，Informix 數據庫通過邏輯日誌 (logical log) 來記錄所有的事務操作及其處理的數據。邏輯日誌的作用之一在於對數據所發生的變化進行記錄以滿足可能的回滾需要。
Informix 數據庫服務器把邏輯日誌分成多個相互分離的磁盤空間，每個磁盤空間稱爲一個邏輯日誌文件。由於邏輯日誌文件的大小和個數由參數指定，整個邏輯日誌的空間是相對固定的，並不能無限制的增長。所以對於邏輯日誌文件的使用是循環進行的。Informix 數據庫服務器按數字順序依次填充空閒的（即狀態爲 free 或 available）的邏輯日誌文件。當第一個邏輯日誌文件變滿時，接着開始填充下一個邏輯日誌文件，直到填充完最後一個邏輯日誌文件。這時，數據庫服務器回到第一個邏輯日誌文件，試圖將其內容釋放，以循環使用 ( 如圖 1)。
圖 1. 循環使用的邏輯日誌
釋放已經使用過的邏輯日誌，需要具備很多條件。其中之一就是該日誌不能包含仍然活動的 ( 即還沒有提交 ) 的事務。 因爲活動的事務隨時存在需要回滾的可能性，如果在事務還沒有提交時，包含該事務記錄的日誌由於被釋放重用，原來的事務操作記錄被覆蓋，當事務由於各種原因需要回滾時，回滾所需的記錄就會缺失，從而導致無法保證事務的原子性和完整性。
那麼，當數據庫服務器需要循環使用某個邏輯日誌文件，而該文件又包含有還沒有提交的事務時，數據庫系統就將被掛起 (hang), 處於一種停滯狀態，任何對數據庫的更新操作都無法繼續，從而影響系統的正常處理工作 ( 如圖 2)。
圖 2. 長事務導致系統掛起
爲了防止這種現象的發生，我們把佔用整個邏輯日誌空間在一定比例以上的事務，就叫做“長事務”。“長事務”意味着可能由於跨越過多的日誌文件，導致需要循環使用的日誌文件不能及時釋放。從而造成數據庫系統掛起無法正常工作的可能性。
與長事務相關的數據庫參數
那麼究竟多長的事務就是“長事務”呢？事實上，“長事務”由一系列數據庫參數決定。
LOGFILES
該參數指定系統初始化或重啓動時創建的邏輯日誌文件的個數。之後系統管理員還可以繼續追加邏輯日誌文件數。Informix 數據庫要求邏輯日誌文件最少有 3 個，最多可以追加到 32,767 個或直至邏輯日誌所在空間 (dbspace) 被佔滿。
LOGSIZE
該參數指定創建的邏輯日誌文件的缺省大小。當系統管理員手工追加日誌文件時，可以重新指定日誌文件大小。
所以邏輯日誌文件的個數和其大小決定了系統可用邏輯日誌空間的總和。
Long-Transaction High-Watermark (LTXHWM)
長事務深水線比例是指整個邏輯日誌空間的一個百分比值。當一個事務佔用整個邏輯日誌空間的百分比超過這個值時，該事務就成爲長事務。數據庫系統系統就會強制對該事務進行回滾（rollback ）， 以防止該事務繼續填充日誌，最終導致日誌需要循環重用時無法釋放而造成系統掛起。
例如，數據庫服務器有 10 個邏輯日誌文件，如果 LTXHWM 設置爲 80 。一個事務（transaction ）從日誌文件 1 （log1 ）開始填充，隨着該事務的更新 (update) ，當其操作填充到第 8 個日誌文件滿時，該事務就到達了長事務深水線比例（LTXHWM ），爲了防止系統掛起，數據庫服務器將回滾該事務。
Exclusive Access, Long-Transaction High-Watermark (LTXEHWM)
當一個事務到達長事務深水線比例（LTXHWM ）後，數據庫服務器會回滾該事務。事務回滾本身也會產生日誌，仍然要繼續填充日誌空間。同時，由於併發事務的存在，其他事務也在不斷填充日誌空間。所以如果在該事務完全回滾之前，日誌空間被填滿，仍然會造成系統的掛起。爲了儘量避免這種情況的發生，我們用獨享的長事務深水線來限制長事物回滾時其他事務對日誌空間的使用。
獨享的長事務深水線也是整個邏輯日誌空間的一個百分比值。當正在回滾的長事務佔用日誌空間的百分比到達這個值時，系統會急劇降低對日誌文件的填充速度。此時，數據庫系統幾乎給予正在回滾的長事務以獨佔使用剩餘日誌空間的權利，以最大限度地保障長事務回滾能夠在日誌空間添滿前能夠順利完成，從而使日誌釋放重用得以實現。
例如，數據庫服務器有 10 個邏輯日誌文件，如果 LTXHWM 設置爲 80, LTXEHWM 設置爲 90 。一個事務（transaction ）從日誌文件 1 （log1 ）開始填充，隨着該事務的更新 (update) ，當其操作填充到第 8 個日誌文件滿時，該事務就到達了長事務深水線比例（LTXHWM ），爲了防止系統掛起，數據庫服務器開始回滾該事務，此時日誌內容由於該事務回滾和其他事務繼續增長，當其操作填充到第 9 個日誌文件滿時，如果該事務還未回滾完成，則到達獨享的長事務深水線比例（LTXEHWM ），這時候數據庫系統會暫停其他事務的操作（除 commit 操作外），留下剩餘的日誌空間，讓該事務回滾，以防止日誌空間在回滾結束前被佔滿。( 如圖 3)
圖 3. 長事務深水線比例（LTXHWM）與獨享的長事務深水線比例（LTXEHWM）示意
DYNAMIC_LOGS
從 Informix Dynamic Server （IDS）版本 9.30 開始，用戶可以通過對數據庫參數中的 DYNAMIC_LOGS 參數進行設置以實現系統邏輯日誌的自動分配。該參數允許用戶在服務器工作狀態動態添加新的日誌並且立即生效，從而動態增加整個邏輯日誌空間的大小，消除或減小長事務處理引起掛機的可能性。
DYNAMIC_LOGS 參數有三個值分別爲 0,1,2：
- 缺省爲 2( 系統自動分配日誌 )。假如當前使用的日誌爲 n，系統自動爲 Transation 檢查 log n+1 的狀態，如果返回的結果爲真 ( 即 Log n+1 無法被釋放而重用 )，系統將在 n 和 n+1 之間加入新的日誌並一直增加到滿足當前 Transation 完成且立即生效。新增加的日誌缺省建立到邏輯日誌最後被添加的 dbspace 中，或根據系統規則建立到指定的 dbspace 中。新增日誌的大小將取已有最大日誌和最小日誌的均值。或根據請求空間的大小進行相應的調整，日誌最小爲 200K。
圖 4. 邏輯日誌的動態分配示意
- 當 DYNAMIC_LOGS 參數設置爲 1 時，系統也自動爲 Transation 檢查 logn+1 的狀態，如果返回的結果爲真 ( 即 Log n+1 無法被釋放而重用 )，系統將等待系統管理員手工在當前日誌後添加日誌，系統管理員可以在任何時間使用 ISA 或 onparams 多種方式爲系統添加日誌。
- 如果 DYNAMIC_LOGS 參數爲 0，系統將不會自動添加日誌也不會出現等待狀況。
什麼情況下會出現長事務
從以上數據庫參數可以看出，長事務與整個日誌空間大小有關，與長事務深水線比例有關。直接來看，在整個邏輯日誌空間相對固定的前提下，當一個事務越大（包含的操作越多），其需要填充的邏輯日誌空間就會越大。如果該事務需要記錄的日誌佔用整個邏輯日誌的百分比超過長事務深水線比例（LTHWM），該事務就成爲長事務。
那麼，如果我們能夠預計最複雜的事務需要填充日誌空間的大小，如果我們分配給系統足夠大的日誌空間（系統整個日誌空間 *LTHWM/100 > 最複雜的事務需要填充的日誌空間），是不是就完全能夠杜絕長事務的發生呢？另外，一個非常小的事務（其實際填充的日誌空間遠遠小於系統整個日誌空間）是不是就一定不會成爲長事務呢？
答案並非如此。
事實上，事務之所以成爲長事務，其所佔日誌空間定義爲該事務從第一條日誌記錄到最終 commit 或者 rollback 記錄之間的所有日誌空間。當這個空間佔用整個邏輯日誌空間的百分比超過長事務深水線比例時，該事務就成爲長事務了。
首先，事務包含的操作的多少隻是決定該事務是否將成爲長事務的因素之一。還有其它一些因素會影響事務佔用邏輯日誌空間的大小。例如，一條 Alter table 雖然僅僅是一個操作，但語句將會爲每一次往新修改了的表中的插入操作生成一條邏輯日誌記錄。數據行的數量與表的大小都將會影響生成的邏輯日誌記錄的數目與大小。操作的數據行數越多，生成的邏輯日誌記錄越多，所佔用的邏輯日誌空間既然越大。
其次，在另外一些情況下，雖然事物的操作和數據行大小並不大，但由於系統併發的存在，事務的持續時間也是一個不能爲用戶所控制的主要的變化量。在事務持續時間中，該事務所佔日誌空間中可能包含了許多其他併發事務的日誌記錄。因此，系統的併發性越大，事務的操作時間越長，事務佔用 ( 跨越 ) 的邏輯日誌空間就越大。一個應用，也許並不需要過多的邏輯日誌記錄空間，但如果用戶允許事務在很長時間內保持打開，這時就可能造成長事務事件。
發生長事務事件的結果及影響
當一個事務所跨邏輯日誌空間的百分比超過長事務深水線比例 (LTXHWM) 時，系統會將該事務標記爲長事務，並開始回滾 (rollback) 該事務。如果此時還沒有達到獨享的長事務深水線比例 (LTXEHWM) ，則系統在回滾該事務的同時允許其他併發事務的繼續操作。當該事務日誌佔用超過獨享的長事務深水線比例 (LTXEHWM) 時，系統會暫停其他併發事務的進行，優先進行該事務的回滾操作，直到事務回滾完成。如果在該事務回滾完成之前，系統邏輯日誌空間已被全部佔滿，則數據庫系統會掛起，無法爲客戶端繼續提供正常服務。
所以，只要配置足夠的邏輯日誌空間和較低的長事務深水線比例 (LTXHWM)、獨享的長事務深水線比例 (LTXEHWM)，就有可能保證長事務的順利回滾。但是，長事務的出現，會影響業務的正常操作，導致該事務無法執行成功。而且，長事務獨享日誌回滾期間，也會影響整個系統的併發效率。
然而，最糟糕的情況莫過於出現長事務回滾完成之前，系統邏輯日誌空間已被全部佔滿，從而帶來致命的系統掛起，給系統運營帶來損失。
如何監控長事務
當數據庫系統發生長事務事件時，可以在所有 onstat 命令的輸出頭上看到。“onstat –”命令（不帶有任何選項）只輸出頭部信息，對於觀察系統的狀態非常有用。其輸出模式如下：
|
1 |
|
當系統出現長事務時，可能的輸出爲：
|
1 |
|
當數據庫系統由於各種原因被阻止時，在以上 onstat 輸出下方還會有如下顯示：
|
1 |
|
其中，“reason”可能的跟長事務相關的值見表 1：
表 1. 系統受阻的原因 ( 跟長事務相關的原因 )
| 原因代碼值 | 原因解釋 |
|---|---|
| LONGTX | Long transaction |
| LBU | Logs full high-watermark |
另外，“onstat -x”命令還可以看到回滾的事務 ( 如圖 5 所示 )。 在輸出的 flag 列中，第三個位置上的標記如果爲“R”，說明該事務正在回滾或已回滾。也可以用“onstat -x|grep R” 命令將其從衆多的事務列表中選出。當然回滾的事務不一定都是長事務。
圖 5. 回滾的事務
有時侯，事務回滾需要很長的時間，如果該事務處於獨享的長事務深水線區域，很多併發的操作無法執行，用戶常常誤以爲系統發生了崩潰。這時，可以用“onstat -lr” 命令，通過觀察邏輯日誌的寫 ( 佔用 ) 情況來判斷系統是否還處於正常的活動工作狀態。
圖 6. 判斷系統是否還處於正常的活動工作狀態
如何避免長事務以及如何處理長事物帶來的系統掛起
保證在系統需要時，有足夠的邏輯日誌空間使用，儘量避免長事務帶來的困擾，維護系統正常運轉，這是數據庫管理員的職責。那麼，該如何避免長事務以及如何處理長事物帶來的系統掛起呢？
首先，最基本的一點是最大限度地保證邏輯日誌可用空間，滿足事務的需要。對於邏輯日誌空間的配置應該考慮到應用中最大的事務的操作的多少，以及各操作可能涉及的數據的多少，從而保證該事務所需要的實際物理日誌空間得以滿足。不考慮併發因素，如果參數的設置滿足如下公式，則不會出現長事務現象。
|
1 |
|
但實際情況遠遠沒有這麼簡單。由於系統併發的不可控性，以及事務執行當時，數據量的不可預知性，我們似乎沒有辦法預知應該爲邏輯日誌分配多少空間。而且，有時侯，容易成爲長事務的 transaction 可能執行頻率相當低（如批量裝載事務，可能一個月，甚至一年才執行一次），如果爲其計算出來的所需日誌空間非常大，那麼預留這樣的日誌空間對於系統的日常運行來說也是相當浪費。
從 Informix Dynamic Server （IDS）版本 9.30 開始，用戶可以通過對數據庫參數中的 DYNAMIC_LOGS 參數進行設置以實現系統邏輯日誌的動態自動按需分配。有了這個參數以後，長事務深水線比例 (LTXHWM) 不再象以前（版本 9.30 以前）那麼關鍵地去影響長事務的發生以及造成系統掛起了。因爲數據庫系統的日誌空間可以動態增長了，直到數據庫所在系統物理空間被佔滿。
動態追加邏輯日誌可以有效防止長事務的發生及由此而引起的系統掛起。噹噹前正在被填充的日誌文件的下一個日誌文件包含有活動（尚未提交）的事務時，系統將允許動態追加邏輯日誌文件。
所以合理設置 DYNAMIC_LOGS 參數，可以有效減小長事務發生的概率。無論是將其設置爲 1( 手工動態追加日誌 )， 還是 2( 自動動態追加日誌 )，都能讓 Informix 數據庫服務器動態即時追加邏輯日誌。隨着邏輯日誌空間的增長，長事務深水線也會增長，事務成爲長事務的機率就會降低。即使由於事物日誌記錄空間的增長速度超過系統追加日誌空間的速度，從而使事務到達長事務深水線比例 (LTXHWM)，在長事務回滾期間（該長事務和其他併發事務繼續產生日誌記錄），數據庫系統仍然可以動態分配追加日誌空間以滿足長事務回滾的需要，直到其回滾完成。
例如， 數據庫服務器配置了 10 個邏輯日誌文件，長事務深水線比例 (LTXHWM) 設置爲 98。假設一個事務從日誌文件 1 開始，其操作填充了日誌 1 到 9，在開始使用日誌文件 10 時，這時候該事務佔用日誌空間比例爲 9/10，還沒有到達 0.98，也就是說還沒有成爲長事務。這時候數據庫服務器開始動態追加日誌文件 11。只要該事務沒有成功完成，這個過程會重複進行直到當數據庫服務器追加到第 50 個日誌文件時，此時，該事務使用到了第 49 個日誌文件，其佔用日誌空間比例爲 49/50，剛好到達 0.98，也就是說該事務成爲長事務，開始進行回滾。
但這樣的情形不會太多，可能還沒有等到系統追加到第 50 個邏輯日誌，該事務已經成功提交 (commit) 了。
保障足夠的邏輯日誌空間以及支持動態日誌空間增長是避免長事務的重要手段。同時，降低長事務深水線比例 (LTXHWM) 和獨享的長事務深水線比例 (LTXEHWM) ，雖然不能減小長事務發生的概率，卻能夠有效減小長事務發生後導致系統掛起的可能性。如果可用的邏輯日誌空間有限，預計發生長事務的可能性較大時建議將長事務深水線比例 (LTXHWM) 設置爲 50， 獨享的長事務深水線比例 (LTXEHWM) 設置爲 60，以保證系統的安全。
但有時， 我們也可能需要根據具體情況對長事務深水線比例 (LTXHWM) 和獨享的長事務深水線比例 (LTXEHWM) 進行調整。如，爲了保證長事務回滾期間系統的併發處理能力，我們可以加大獨享的長事務深水線比例 (LTXEHWM)；爲了順利運行一個計劃的未知大小的事務（如批量加載），我們可以適當加大長事務深水線比例 (LTXHWM) 以保證該事務不會成爲長事務而遭到回滾。如果系統有充分足夠的空間，在 DYNAMIC_LOGS 參數設置爲 1 或 2 的前提下，想讓一個未知大小的事務順利執行而不受長事務問題的困擾，甚至可以考慮將長事務深水線比例 (LTXEHWM) 設置爲 100，從而迫使數據庫服務器在需要的時候持續追加邏輯日誌，直到該事務執行成功 (commit)。同樣，爲了保證長事務回滾期間系統的併發處理不受影響，可以將獨享的長事務深水線比例 (LTXEHWM) 設置爲 100，這樣一來，數據庫服務器可以不斷追加足夠多的邏輯日誌，以保證長事務回滾結束，防止系統因缺乏空閒邏輯日誌而掛起。
需要注意的是，即使數據庫系統的日誌空間可以動態增長，一旦受到系統物理空間的限制，長事務深水線比例 (LTXHWM) 和獨享的長事務深水線比例 (LTXEHWM) 參數仍然用來防止邏輯日誌被事務佔滿而無法釋放重用的情況發生。只是這種情況發生的概率應該更小。而一旦發生，預示着應用系統的嚴重隱患。所以加強應用系統對於處理長事務的考慮，通過減小事務的長度，更頻繁地提交事務等手段，都能很好地控制長事務的發生。
一般來說，我們對參數的建議如下 :
- 如果系統有大量的物理空間，DYNAMIC_LOGS 參數可以設置爲 1 或 2, 長事務深水線比例 (LTXHWM) 和獨享的長事務深水線比例 (LTXEHWM) 分別設置爲 80 和 90。
- 如果因爲分配給數據庫系統的邏輯日誌空間有限，DYNAMIC_LOGS 參數設置爲 0，長事務深水線比例 (LTXHWM) 和獨享的長事務深水線比例 (LTXEHWM) 分別設置爲 50 和 60。
這裏只是對一般系統的一個通常的建議，如果因爲某種需要，降低長事務深水線比例 (LTXHWM)，就意味着增加了長事務出現的可能性，當然還可以通過分配更多的日誌空間來做補償。
如果預防不力，在實際生產系統中發生由於長事務而導致的系統掛起，又該如何處理呢？
發生系統掛起事件，從數據庫日誌（online.log ）中可以看到相應的事件信息。爲了解決這個問題，通常有如下做法：
- 如果想讓該長事務繼續進行，需要：
- 增加一個 dbspace 或者在原有 dbspace 上增加 chunk, 以增加日誌可用空間
- 恢復該事務處理
- 如果無法增加更多的空間給數據庫服務器，則需要終止該事務
- 發出“onmode -z ”命令終止相應長事務
- 關閉 (shutdown) 數據庫服務器，進行重啓 (oninit)
- 當數據庫服務器重啓進入快速恢復（fast-recovery）狀態時，該事務被回滾。然後執行如下步驟：增加更多的磁盤空間，直到該事務回滾成功完成。
- 如果由於其他原因，系統無法從掛起狀態下恢復，唯一的途徑就是從備份中進行恢復：
- 執行一個基於時間點的恢復，將系統恢復至該長事務開始前的時間點
- 執行一個完全的 0 級恢復，釋放掉所有邏輯日誌空間
結束語
長事務是數據庫系統爲了保護自身的良好運行，防止由於事務佔用過多的日誌空間而採取的一種控制手段。在系統運行過程中，我們應該合理設置與長事務相關的數據庫參數，有效避免長事務的發生，同時積極監控系統狀態，在發生長事務的時候，根據具體需求和情況給予合理處理，從而保證系統的正常運行。