Informix培训教材整理之产品介绍

INFORMIX 公司及产品介绍

 　　提起INFORMIX公司，相信大家一定不会陌生。在DBMS业界，是技术出众，产品成熟，信誉和服务都不错，尤其在中国的市场占有率正逐步提高。

 　　这里简单介绍一下其历史和部分产品，以及使用产品中获取帮助的方法。

 　　详细的情况可到INFORMIX公司网站（或.cn）查询。 

   历史

 公司前身是Relational Database System,Inc。 

时间   事件     

1980   Relational Database System,Inc成立    

1981   第一个产品C-ISAM     

1982   发行pre-SQL套件：Informer query language, Perform form manager, Ace report wirter     1983   Informix 诞生（Inform[er]和UNIX的组合）     

1986   Informix-4GL     

1986   发行Informix-Turbo     

1988   公司更名Informix Software,Inc     

1988   Infomrix-4GL/RDS、Informix-4GL/ID及Informix-4GL p-Code版推出     

1988   发行WingZ     1990   由Informix-Online取代Informix-Turbo     

1993   发行Informix-OnLine Dynamic Server     

1994   发行Informix-NewEra     

1995   新版Informix-NewEra     

1996   与Illustra合并    

1999   发行Infromix for Linux   

1999   IDS2000   

   产品分类 

 主要包括：数据库服务器、连接、应用程序开发工具；用户访问工具；终端用户信息访问工具、在线进程分析工具。 

  获取帮助在：

 WWW： 和

 Usenet ： comp.database.Informix

 FTP： ftp.Informix.com     

 

 

一　　操作系统与硬件

 

      1.从全局着眼

      通常只观察系统性能量度是不够的，需要考虑整个系统如磁盘/控制器、CPU、网络的使用情况。

      2.操作系统工具：sar,vmstat,iostat等

      UNIX供应商提供了多种系统监视实用程序，其中包括sar,vmstat,iostat等普通的命令行实用程序，许多供应商还提供了图形化的工具（如HP的GlancePlus)。

      使用这些实用程序时应该非常仔细，它们经常报告看似相似的度量，但是不同的供应商甚至同一些供应商不同版本之间的特定量度的确切定义是不完全相同的。

      3.磁盘与控制器

      使用操作系统监视工具来调整磁盘I/O

      试图均衡所有磁盘和控制器I/O，并非只对系统磁盘

      RAID5没有大的硬件缓存，则写磁盘的性能就会很低

      尽量让磁盘繁密比率低于30％，如果达到60％，会发现性能将受到破坏。

      不要过分担心iowait时间，这一量度不易解释其内在含义，常使人误入歧途。

      仔细定位原始分区，尽量减少每个磁盘上磁头的移动。

      操作系统/硬件镜像可以帮助提高性能，一般比INFORMIX镜像更有助于性能的提高，，但这要依供应商的支持程度而定。

      4.网络

      不同UNIX供应商对TCP/IP参数提供不同级别的控制，以下是可以对性能起作用的参数

      流式缓冲区的数目

      对于客户机/服务器的高负载，多一些缓冲区可以改善性能

      数据包（Packet)的大小

      对客户机经常发送/接收大量数据的可靠网络而言，增加数据包大小可能会提高吞吐量。对客户机经常发送/接收少量数据的不太可靠的网络，数据包的尺寸小一些可能会好些。数据包的大小与sqlhosts文件中指定的缓冲区大小相互关联。       

      5. 连接队列长度

      同时有许多连接请求时，它会影响连接请求的性能，增加该值可以减少用户连接的重试次数。       

      6.CPU使用情况

      CPU使用情况监测是系统性能调整的重要方面

      系统或INFORMIX的CPU使用率高不一定表示出现性能问题

      应尽可能利用可利用的资源，这在缺少资源而造成处理延误时可能会成为问题。

      可以通过onstat -p 监测CPU使用的总体情况

      每个VP的CPU使用情况可以通过onstat -g glo来监测

      系统总体CPU使用情况可以通过sar,vmstat来监测

      应该查找什么：

      线索就绪队列（onstat -g rea)

      如果一直显示有大量线索等待运行（多于10到15个）则表示严重缺少CPU VP资源。

      大量闲置的CPU（sar,vmstat等）

      如果发现就绪队列缺少CPU VP资源，并且有多余的系统CPU ，试着增加另一个CPU VP 。一般不应有多于物理CPU数目的CPU VP，但这一点并非永远成立。

      若没有空余的处理器，不要再增加CPU VP。CPU 利用率接近100％时再增加CPU VP，只会使情况变得更糟。

      大量使用CPU 其它进程

      也许这些进程应当在其它主机或者系统闲时运行

      CPU VP数小于等于物理CPU数

      动态可伸缩结构（DSA)设计目标是让CPU数小于物理CPU数以获得优化的性能，但有的环境下，增加CPU VP使其大于物理CPU数可能会改善性能，真是这样的话，这可能是系统的BUG。维护应该记录问题，从技术支持处寻求帮助。