在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官方文档或联系技术支持获取进一步的帮助。
亿速云「云服务器」，即开即用、新一代英特尔至强铂金CPU、三副本存储NVMe SSD云盘，价格低至29元/月。点击查看>>
