Informix技巧

Informix技巧4则本文内容均来自网络，这里仅是组织整理，方便记忆和查阅，以及供更多的人学习，如果有兴趣可到文中的“出处”查看原文。

--------------------------------------------------------------------------------

1. UPDATE STATISTICS FOR TABLE tablename( 出处:ChinaUnix )
     Informix 数据库服务器中的优化器为SQL语句的查询提供最有效的策略,估计查询策略的代价需要准确的统计信息(包括:记录数,表空间的页数,记录长度,字段不同值个数,索引的层数,索引叶结点数目,索引是升序还是降序或聚类索引),但是由于维护这些统计信息的代价是很大的,所以informix系统不是在每次修改时对统计值更新.因此当我们对数据库进行了大量的数据库操作（删除）时，如果想提高查询的效率，最好手动的更新系统表的统计信息，命令格式如下：
 UPDATE   STATISTICS   FOR   TABLE  tablename

2." could not do a physical order read to fetch next row" ( 出处:JavaYou )
      在大数据量操作数据库的时候，容易出现异常："could not do a physical order read to fetch next row"，这是 是因为Informix默认锁等待时间为0，即在操作（update、delete等）数据库的时候，如遇到其他操作也在使用同一张表的情况时，则不等待和返回异常。
       最简单的解决方法就是每次在获取新的（注意是新的，原有的连接也无妨，但影响效率）数据库连接时，首先执行设置连接的锁等待时间的Sql：
 SET  LOCK MODE  TO  WAIT  10    -- 意思是设置锁等待时间为10ms

 

3."DBSERVERNAME不在sqlhosts文件中 " ( 出处:JavaYou )
      在Windows下如果碰到问题：当初始化数据库或者做其它操作的时候提示DBSERVERNAME不在sqlhosts文件中，事实上Windows操作系统的Informix是不需要sqlhosts文件的，该文件仅存于UNIX操作系统。
       解决办法是：检查这样一个服务是否启动，该服务的名称是：Remote Registry Service，必须保证该服务启动。因为Informix数据库很多配置信息都存放在注册表中，如果没有启动该服务，则数据库无法读取注册表的信息。

 

4.导入导出
[导出]
 UNLOAD  TO  dataFile.dmp  SELECT   *   FROM  tablename
[导入]
 LOAD   FROM  dataFile.dmp  INSERT   INTO  tablename

***********************************************************************************************

使用3大数据库开发时的问题
在使用过的三大数据库Informix、DB2、Oracle中，因为涉及到不同的项目，所以都接触过，其中在开发使用中，出现不少最让人记忆深刻的问题，基本上都和数据库的不同实现特性有关，但一不小心还是让你深陷重围，下面举例一二，供大家参考：

Informix：

最大的问题出现在大数据量操作的时候会出现异常： "could not do a physical order read to fetch next row"，查询Error Message手册和其他手册都查不到解决方法，无从下手，具体表现在大数据量操作数据库的时候，容易出现，最后终于在一个数据库论坛找到解决问题所在。

一方面可以在隔离级别的选择上进行改动（但并不彻底），另一方面则是因为Informix默认锁等待时间为0，即在操作（update、delete等）数据库的时候，如遇到其他操作也在使用同一张表的情况时，则不等待和返回异常。

最简单的解决方法就是每次在获取新的（注意是新的，原有的连接也无妨，但影响效率）数据库连接时，首先执行设置连接的锁等待时间的Sql：

SET LOCK MODE TO WAIT 10 （意思是设置锁等待时间为10ms），

这样基本解决问题，不再出现异常情况。

Oracle：

在Informix环境下开发的项目系统，割接到Oracle应用系统的时候，经过一段时间运行，出现 "ORA-01000: maximum open cursors exceeded" 的错误，表示 cursors 已经用完，无法继续数据库操作，主要原因是由于在一个进程打开的游标数超过设定值。

查询资料后发现，单纯增大cursors值并不是彻底解决的方法，主要还是在于应用系统的代码问题，大都因为在循环内使用了preparedStatement或createStatement，每执行一条创建意味着在Oracle中增加使用一个Cursor。

解决方法：executeQuery、executeUpdate等操作后立即释放资源，或把创建statement或preparedStatement的方法移出循环，避免不必要的Cursor使用情况，这样做带来的操作效率可以提高至少10倍，在preparedStatement时更是如此。

DB2：

程序运行时，报出连接数超过最大限制！

初一看，以为DB2的版本不对口所以有限制，可怎么的也是Enterprise版啊，于是翻箱倒柜，找到主要还是数据库的配置参数设置问题。 默认DB2的应用程序连接数设置都不高，需要根据应用手工自行调整，在控制中心－数据库－选择相应数据库－右键，选择配置－应用程序－最大活动应用程序数，注释为：指定可同时连接到数据库的最大（本地和远程）应用程序数（1－5000），

更改加大同时连接数据库的参数值即可。

 informix临时表的存放位置
根据informix的语法手册，create temp table或者select ... into temp语句，会显式创建临时表，如果在语句中没有包含存放位置子句的话，临时表的存放位置应该放在环境变量DBSPACETEMP或者ONCONFIG 参数DBSPACETEMP所指定的Dbspace中。

但是在实践中，发现事实并非如此，如果create temp table没有带with no log子句，那么该临时表不会放到DBSPACETEMP所指定的Dbspace，而是放到informix的系统Dbspace——rootdbs。

经过查询资料，终于弄明白原因所在。

通常用户创建的Dbspaces（相当于oracle中的tablespace）都是带日志功能的，但临时类型Dbspace（创建时指定Temp标志为Y）例外，是不带日志功能的。

创建临时表时，如果没有指定with no log子句，那么informix就会根据表所在数据库的日志模式，来设定表的日志模式。大多数情况下，我们用户为了保证数据可靠性，都会开放数据库日志模式。于是，informix只能选择那些带日志功能的Dbspaces来存放临时表，而不幸的是，管理员总是把一些临时类型Dbspace列在 DBSPACETEMP变量中。这就出现——虽然指定DBSPACETEMP，但informix仍然把临时表放在rootdbs的问题。

解决方法就是在DBSPACETEMP变量中，添加一些非临时类型的Dbspace（临时和非临时Dbspaces可以共存）。

另：DBSPACETEMP变量应该还要放一些临时类型的Dbspace，用于那些非显式生成临时表的情况，例如：大表join，排序等等。