在Ubuntu系統上安裝和配置Informix數據庫時，用戶可能會遇到一些常見問題。以下是一些常見問題的及其解決方案：
邏輯日志滿
- 故障現象：數據庫不再進行任何操作，使用
onstat –l 命令觀察邏輯日志狀態，所有的邏輯日志都處于已使用未備份狀態，即flags 為 U------ 標志。
- 故障分析：由于數據庫的大部分操作都需要記錄邏輯日志，所以如果邏輯日志由于各種各樣的原因被充滿都會導致數據庫停止正常的操作，等待邏輯日志空間的釋放、重新再利用。這一般會由于數據庫邏輯日志沒有及時備份、數據庫邏輯日志空間分配過小、邏輯日志里面包含活動事務、包含檢查點信息等原因。
- 故障處理：檢查是否是由于邏輯日志備份出現問題，如果是不能備份請查找不能備份的原因，可能是由于磁帶滿或磁帶機出現故障，或者是磁帶設備繁忙；個別情況下即使邏輯日志標志為已備份但是仍然是不可使用的，包括：該邏輯日志包含活動的事務信息，由于數據庫需要考慮其可能的回滾操作，因此是不會讓該邏輯日志的內容被覆蓋的，可以通過
onstat –x 檢查其 beginlg 來確定事務的邏輯日志起始位置；包含檢查點信息，可以通過 onstat –l 觀察 flags 的最后一位為 L 的邏輯日志的位置，在它之后的邏輯日志即使已經備份也是不可使用的，因為這些邏輯日志內容將會在快速恢復中使用到。在這些情況出現以后如果暫時不能快速的處理，在IDS 9.3x 或以后的版本上可以使用邏輯日志聯機增加的功能，只要有空閑的 chunk 空間，使用 onparams -a -d <DBspace> -s <size> -i 即可在當前邏輯日志后增加新的邏輯日志，并且不需要執行 0 級備份。
頻繁的鎖沖突
- 故障現象：在正常的數據庫操作中會經常出現-243、-244 等一類的鎖錯誤碼出現 -243 Could not position within a table table-name.-244 Could not do a physical-order read to fetch next row。
- 故障分析：數據庫在進行修改操作的時候為了防止其他用戶的同時修改，都會在修改所涉及的數據上設置對應的鎖，如果其他用戶再訪問到這些已經被放置上鎖的數據，就會出現鎖失敗。
- 故障處理：調整數據庫隔離級別，例如使用 dirty read；將數據庫表的缺省頁級鎖修改為行級鎖；設置鎖等待時間；調整應用 SQL，提高執行效率，盡量快的完成事務處理，釋放資源；如果需要快速處理鎖沖突的情況，在確定鎖的實際擁有者以后可以確定是否應該終止其操作，執行
onmode –z sid Kill specified session id，以達到釋放鎖資源的目的。
長事務問題
- 故障現象：在數據庫日志里面出現發現長事務的提示，受影響的事務處于回滾狀態，個別情況下會導致整個數據庫實例的其他數據庫會話都停止執行。
- 故障分析：當一個活動事務它所占用的邏輯日志個數的比例達到或超過 LTXHWM 所設定的值，數據庫就會判定該事務為一個長事務，對該事務進行回滾操作，如果這個時候邏輯日志的使用個數仍然持續上漲達到或超過 LTXEHWM 所設定的值，則數據庫會停止其他會話的正常運轉，全力保證該長事務的回滾操作。
- 故障處理：根據數據庫日志里面所提供的信息可以很方便的發現具體是那一個事務造成了長事務。系統在將某個事務判定為長事務以后就會自動對其進行回滾操作。事后可以有針對性的調整應用將大的事務劃分為小事務進行提交；避免一個活動事務長時間沒有后續的操作；提供充足的邏輯日志空間。
數據庫 chunk 出現異常，I/O 失敗
- 故障現象：數據庫日志中出現 chunk IO 錯誤，使用
onstat –d 觀察 chunk flag 的狀態是 down 的狀態，數據庫操作中不能操作包含在這些 chunk 中的數據，如果使用到這些數據可能會返回錯誤，嚴重情況下會導致數據庫宕機。
- 故障分析：由于發生 IO 錯誤，數據庫不能正常的操作包含在受影響 chunk 中的數據，所有的操作請求都將失敗。這可能是由于磁盤設備出現問題、chunk 所使用的設備不存在、使用的鏈接設備不存在、設備的權限錯誤等可能性。
- 故障處理：根據前面所列出的可能性逐一進行檢查。一個快速確定存儲設備是否可用的辦法是：使用
dd 命令實際讀取。
希望這些信息能幫助您解決在Ubuntu系統上使用Informix數據庫時遇到的問題。
