在Ubuntu系統上安裝和運行Informix數據庫時，可能會遇到各種故障。以下是一些常見的故障及其排查方法：
故障現象：數據庫不再進行任何操作，使用 onstat –l 命令觀察邏輯日志狀態，所有的邏輯日志都處于已使用未備份狀態，即flags 為U------ 標志。
故障分析：由于數據庫的大部分操作都需要記錄邏輯日志，所以如果邏輯日志由于各種各樣的原因被充滿都會導致數據庫停止正常的操作，等待邏輯日志空間的釋放、重新再利用。這一般會由于數據庫邏輯日志沒有及時備份、數據庫邏輯日志空間分配過小、邏輯日志里面包含活動事務、包含檢查點信息等原因。
故障處理：
onstat –x 檢查其 beginlg 來確定事務的邏輯日志起始位置。onstat –l 觀察flags 的最后一位為L的邏輯日志的位置，在它之后的邏輯日志即使已經備份也是不可使用的，因為這些邏輯日志內容將會在快速恢復中使用到。onparams -a -d DBspace -s size -i 即可在當前邏輯日志后增加新的邏輯日志，并且不需要執行0級備份。故障現象：在正常的數據庫操作中會經常出現-243、-244等一類的鎖錯誤碼出現。 故障分析：數據庫在進行修改操作的時候為了防止其他用戶的同時修改，都會在修改所涉及的數據上設置對應的鎖，如果其他用戶再訪問到這些已經被放置上鎖的數據，就會出現鎖失敗。 故障處理：
partnum，可以通過查詢 systables 里面的 partnum，也可以通過執行 oncheck –pt database:tabname 查看 Partition partnum 來獲得。onstat –k grep partnum 來查找相應的信息，partnum 為上一個步驟獲得的結果，需要使用具體的十六進制值來替換，觀察其 owner 字段的地址信息。onstat –u grep address 來獲得實際的 session 信息，address 為上一個步驟獲得的結果，這是就可以找到具體的鎖的擁有者。onmode –z sid Kill specified session id，以達到釋放鎖資源的目的。故障現象：在數據庫日志里面出現發現長事務的提示，受影響的事務處于回滾狀態，個別情況下會導致整個數據庫實例的其他數據庫會話都停止執行。
故障分析：當一個活動事務它所占用的邏輯日志個數的比例達到或超過 LTXHWM 所設定的值，數據庫就會判定該事務為一個長事務，對該事務進行回滾操作，如果這個時候邏輯日志的使用個數仍然持續上漲達到或超過 LTXEHWM 所設定的值，則數據庫會停止其他會話的正常運轉，全力保證該長事務的回滾操作。
故障處理：
INFORMIX 9.3X 以后的版本中可以通過動態增加邏輯日志的手段避免由于長事務帶來的一些不良影響，在長事務回滾過程中如果邏輯日志空間被消耗完畢，如果 DYNAMIC_LOGS 設置為2，數據庫服務器會自動在最后創建的邏輯日志所存在的 dbspace 上查找空余空間，按照最后創建的邏輯日志的大小自動在當前邏輯日志之后新增邏輯日志，如果不能滿足需要則會創建失敗，需要管理員手工添加。故障現象：數據庫日志中出現 chunk IO 錯誤，使用 onstat –d 觀察 chunk flag 的狀態是 down 的狀態，數據庫操作中不能操作包含在這些 chunk 中的數據，如果使用到這些數據可能會返回錯誤，嚴重情況下會導致數據庫宕機。
故障分析：由于發生 IO 錯誤，數據庫不能正常的操作包含在受影響 chunk 中的數據，所有的操作請求都將失敗。這可能是由于磁盤設備出現問題、chunk 所使用的設備不存在、使用的鏈接設備不存在、設備的權限錯誤等可能性。
故障處理：根據前面所列出的可能性逐一進行檢查。一個快速確定存儲設備是否可用的辦法是：使用 dd 命令實際讀取。
通過以上步驟和方法，您可以有效地排查和解決在Ubuntu系統上運行Informix數據庫時可能遇到的各種故障。如果問題依然存在，建議參考Informix官方文檔或聯系技術支持獲取進一步的幫助。
