1. 逻辑日志满
故障现象：数据库停止所有操作，使用onstat –l命令查看逻辑日志状态，所有逻辑日志均显示“已使用未备份”（flags为U------）。
故障分析：主要因逻辑日志未及时备份、空间分配过小、包含活动事务或检查点信息导致。
解决方法：① 检查逻辑日志备份流程，修复磁带满、设备故障或繁忙等问题；② 若日志标志显示已备份但仍不可用，通过onstat –x查看beginlg确定活动事务起始位置，或通过onstat –l检查flags最后一位为L的日志（包含检查点信息，不可覆盖）；③ 在IDS 9.3x及以上版本中，使用onparams -a -d <DBspace> -s <size> -i命令动态增加逻辑日志（无需0级备份）。
2. 锁表问题
故障现象：执行数据库操作时报-243（无法定位表中数据）、-244（无法物理读取下一行）等错误，提示“Could not position within a table”或“Could not do a physical-order read to fetch next row”。
故障分析：数据库为防止并发修改，会对操作数据加锁，其他用户访问锁定的数据时会触发锁冲突。
解决方法：① 执行onstat –u获取会话信息，定位锁的拥有者；② 调整隔离级别（如使用dirty read）；③ 将表的缺省页级锁修改为行级锁；④ 设置锁等待时间（避免无限等待）；⑤ 优化SQL语句（减少执行时间，快速释放锁）；⑥ 若锁冲突严重，通过onmode –z sid终止锁拥有者会话（需谨慎操作）。
3. 数据库无法启动
常见原因：① 未正常关闭导致共享内存未清理；② onconfig配置文件错误（如ROOTPATH路径不存在或权限不足）；③ 磁盘空间不足；④ 端口被占用。
解决方法：① 若启动时报“potential instance overwrite detected”，在onconfig中将FULL_DISK_INIT设为1（允许初始化覆盖），初始化成功后该参数会自动变为0（需避免每次启动都修改，可通过脚本固定）；② 检查onconfig文件中的ROOTPATH（rootdbs路径）、DBSERVERNAME（服务器名称）等参数是否正确，确保路径存在且权限为informix:informix（chmod 660）；③ 使用df -h检查磁盘空间，清理无用文件；④ 使用netstat -apn | grep oninit检查端口（默认1526）是否被占用，修改sqlhosts中的端口或终止占用进程。
4. SQLCODE错误
常见错误及解决方法：① SQLCODE 271：表空间或数据库空间满，无法插入新行。解决：使用onstat -d查看表空间使用率，增加数据文件（onspaces -a）或清理无用数据；② SQLCODE 329：数据库不存在或无访问权限。解决：检查数据库名称拼写，使用onstat -d确认数据库是否存在，确保informix用户对数据库目录有读写权限；③ SQLCODE 387：用户无连接权限。解决：使用grant connect to <username>为用户授权；④ SQLCODE 1215：值过大无法存入INTEGER类型。解决：修改字段类型为DECIMAL或BIGINT；⑤ SQLCODE 201：SQL语法错误。解决：检查SQL语句格式（如关键字拼写、括号匹配），使用dbaccess工具预执行语句。
5. Chunk I/O失败
故障现象：onstat -d显示chunk的flag状态为down，数据库无法操作该chunk中的数据，报“I/O error”或“chunk unavailable”。
故障分析：因磁盘设备故障、chunk路径不存在、权限错误或设备未挂载导致。
解决方法：① 使用dd if=<chunk_path> of=/dev/null bs=1024 count=100命令读取chunk设备（仅读操作），确认设备是否可用；② 检查chunk路径是否存在（如/opt/informix/chunks/datadbs1），若不存在则创建并设置正确权限；③ 确认磁盘设备已挂载（mount | grep <device_name>），未挂载则挂载设备；④ 检查onconfig中的ROOTPATH、DBSPACEDBS等参数指向的路径是否正确。
6. 长事务问题
故障现象：数据库日志中出现“long transaction detected”提示，受影响的事务处于回滚状态，严重时导致其他会话停止执行。
故障分析：当事务占用的逻辑日志数量达到LTXHWM（长事务高水位线，默认50%）时，数据库判定为长事务并开始回滚；若回滚期间逻辑日志使用量达到LTXEHWM（长事务极高水位线，默认75%），则停止其他会话以保证回滚完成。
解决方法：① 根据日志中的事务ID（trxid），使用onstat -x或onstat -k定位锁拥有者（owner字段），再通过onstat -u找到对应会话ID（sid）；② 优化应用逻辑，将大事务拆分为小事务（每处理1000-5000条数据提交一次）；③ 避免活动事务长时间闲置（如前端应用崩溃导致事务未提交），设置应用层的连接超时机制；④ 若长事务无法快速回滚，可考虑重启数据库（需提前备份数据）。
7. Docker环境下Informix问题
常见场景：容器内Informix无法启动、端口无法访问、数据持久化失败。
解决方法：① 确保Docker镜像正确（如使用IBM官方ibm/informix-developer-database镜像），拉取镜像时指定版本（docker pull ibm/informix-developer-database:latest）；② 启动容器时映射正确端口（-p 1526:1526，默认SQL端口），挂载数据卷（-v /host/path:/opt/IBM/informix/data，确保数据持久化）；③ 检查容器内onconfig配置（如NETTYPE设为soctcp，HOST设为localhost），确保网络配置正确；④ 查看容器日志（docker logs <container_id>），定位启动错误（如端口冲突、权限不足）。