在CentOS系统上安装和运行Informix数据库时，可能会遇到各种问题。以下是一些常见问题的解决方案：
错误代码 -209：描述：不兼容的数据格式。解决方法：试图对由INFORMIX—SQL早期版本生成的数据库使用INFORMIX—SQL。在数据库上运行 DBUPDATE ，该程序将数据库改为适合当前INFORMIX—SQL版本的数据库。
错误代码 -210：描述：路径太长。解决方法：INFORMIX—SQL要求的路径名不得70个字符，减少路径名的长度。
错误代码 -113：描述：没有当前记录。解决方法：确保执行查询以生成当前列表。
错误代码 -114：描述：文件名太长。解决方法：减少文件长度，命名其小于等于8个字符(DOS)或小于等于10个字符(UNIX)。
错误代码 -116：描述：不能分配内存。解决方法：检查可用内存，减少复合语句或表格。
错误代码 -118：描述：不能读事务日志记录。解决方法：运行 dblog 程序确定哪个记录有问题。
错误代码 -119：描述：不能打开日志文件。解决方法：检查文件是否存在，路径名是否正确，以及是否具有适当权限。
错误代码 -121：描述：不能写日志文件记录。解决方法：检查用户对日志文件的权限。
错误代码 -122：描述：在没有事务处理的数据库中出现 BEGIN WORK 。解决方法：确保在 COMMIT WORK 或 ROLLBACK WORK 之间执行 BEGIN WORK 。
错误代码 -123：描述：不能用NFS系统的操作。解决方法：检查是否能在网络上访问远程文件。
错误代码 -124：描述：没有可分配内存。解决方法：检查数据库管理转换内存空间。
错误代码 -125：描述：没有找到 BEGIN WORK 。解决方法：确保在 COMMIT WORK 或 ROLLBACK WORK 之间执行 BEGIN WORK 。
错误代码 -126：描述：跟踪轨迹已存在。解决方法：在一人表中没有删除当前的跟踪轨迹时，不能指定新的跟踪轨迹。
错误代码 -200：描述：标识符太长。解决方法：标识符不能长于18个字符，应选择一个新的具有适当长度的标识符。
错误代码 -201：描述：发生语法错误。解决方法：检查RDSQL语句是否误拼，关键字顺序是否有错，或者在查询中含有INFORMIX—SQL的保留字。
错误代码 -202：描述：在语句中发现非法字符。解决方法：删除非法字符(通常为不可打印的控制字符)或重写语句。
错误代码 -203：描述：在语句中发现非法整数。解决方法：整数必须在-2,147,483,647到2,147,483,647之间。检查是否带有小数部分或超出值域，以及数字中是否含有字母。
错误代码 -204：描述：在语句中出现非法浮点数。解决方法：检查是否在数字位置上输入了一个字母。
错误代码 -205：描述：不能对视图使用ROWID。解决方法：重新构造语句，以使视图中不包含虚拟字段。
错误代码 -206：描述：指定的表名不在数据库中。解决方法：检查语句中表名拼写是否有误。
错误代码 -208：描述：在查询过程中内存分配失败。解决方法：减少查询或程序的复杂程度。
逻辑日志满：故障现象：数据库不再进行任何操作，使用 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 等一类的锁错误码出现。故障分析：数据库在进行修改操作的时候为了防止其他用户的同时修改，都会在修改所涉及的数据上设置对应的锁，如果其他用户再访问到这些已经被放置上锁的数据，就会出现锁失败。故障处理：调整数据库隔离级别，例如使用 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 命令实际读取。
网络连接问题：
sudo firewall-cmd --permanent --add-port=1521/tcp
sudo firewall-cmd --reload
sudo systemctl status informix
sudo systemctl start informix
sudo systemctl enable informix