Informix是IBM公司出品的关系数据库管理系统（RDBMS）家族。作为一个集成解决方案，它被定位为作为IBM在线事务处理（OLTP）旗舰级数据服务系统。 IBM对Informix和DB2都有长远的规划，两个数据库产品互相吸取对方的技术优势。在2005年早些时候，IBM推出了Informix Dynamic Server（IDS）第10版。目前最新版本的是IDS11（v11.50，代码名为“Cheetah 2”），在2008年5月6日全球同步上市。
Infomix数据库发展历程
1980年
在一家早期的S-100/CP/M公司Cromemco工作的Roger Sippl和Laura King开发了一个基于ISAM技术的小型的关系数据库，作为一个报表记录器软件的一部分。
1980年，Sippl和King离开Cromemco去开发关系数据库系统（RDS）。他们的第一个产品叫做马拉松（Marathon），本质上是一个他们以前那个ISAM作品的16位版本，并且在Onyx操作系统上发布，这种Onyx操作系统是一个为早期的ZiLOG微处理器开发的Unix操作系统。
在开发RDS的时候，他们把目光转移到了新兴的RDBMS市场，并且在1981年发布了他们自己的一个产品：Informix（INFORMation on unIX）。它包含了他们自己的Informer语言。它具备了ACE报表记录器的特性，用来把数据从数据库里释放出来，并且呈现给用户以供读取。它还具备了PERFORM屏幕格式工具的特性，可以让用户实现交互式的查询并且编辑数据库里的数据。这个产品的最终版本是1986年的3.30版。
在1985年，他们引进了一种新的基于SQL的查询引擎，作为INFORMIX-SQL（或ISQL）1.10版（1.00版一直没有发行）的一部分。这个产品同样包括了SQL和PERFORM的SQL变量。ISQL和早期的Informix产品最显著的区别就在于将数据库存取码分散至一个引擎进程中（sqlexec），而不是将其直接嵌入客户端，这样来为和用户的电脑分离开的数据库服务器上的客户端-服务端运算创造条件。而基础的基于ISAM的文件存储引擎就被称作C-ISAM。
尽管在上世纪80年代Informix一直扮演一个小角色，但是随着Unix和SQL在80年代走向流行，他们的命运随之改变。在1986年，他们已经强大到自己独立募股，而且将公司改名为Informix Software。他们的产品包括INFORMIX-SQL 2.00版和INFORMIX-4GL 1.00版，两个产品都包含了数据库引擎和开发工具（为程序员准备的I4GL，和为普通用户准备的ISQL）。
一系列的产品随之发布，包括最初被认为是INFORMIX-Turbo的新的查询引擎。Turbo利用了新式的，比C-ISAM更对多用户性能有好处的RSAM。在1989年的4.00版出版后，Turbo被命名为INFORMIX-OnLine（一部分原因是因为它允许服务器运行在运行时，并且用户正在修改数据，而数据库的备份照样连贯进行），而且最初的基于C-ISAM的服务器被工具（ISQL和I4GL）所分割开来，并且被命名为INFORMIX-SE（标准版）。在1990年年末的时候，Informix OnLine 5.00版本问世，而且包括了完整的对拥有两步式工作提交和存储过程的分布式交易的支持。在5.01版中增加了对触发器的支持。
1988年
在1988年，Informix将Innovative Software公司收购，后者研发了著名的基于DOS和Unix的办公系统软件SmartWare，和具有革新意义基于Apple Macintosh平台的的电子制表软件WingZ。
1994年
随着Informix在办公自动化领域的失败，1994年他们重新把精力集中到发展当中的数据库服务器市场。同年，在与Sequent Computer Systems的协作下，Infomix发布了具备动态可扩展结构（DSA）的6.00版的数据库服务器。
DSA将产品的核心引擎做了很大改动，支持了横向和纵向的并行功能。并且基于和很多先驱与软件生产商（比如Sun Microsystems，Hewlett-Packard）都相继追随的对称多处理系统完美搭配的多线程核心。这两种并行模式让产品在扩展性上处于市场领先地位，不论是OLTP还是data warehousing。
如今我们熟知的Informix Dynamic Server（当初考虑过命名为Obsidian，而后来命名为Informix OnLine Dynamic Server），它的第7版在1994年震撼了市场。当时正式对称多处理技术（SMP）系统刚刚开始盛行，而且Unix已经开始变为服务器操作系统的主流。第7版基本上成为领先于其他竞争者的一代产品，而且不断地在性能评测上胜出。这场胜利的结果使得Informix在1997年轻而易举地将Sybase挤下去，登上了数据库世界的亚军宝座。
在第7版的成功的基础上，Informix将他们核心数据库研发的投资分为两个焦点。第一个是一开始所谓的XMP（for eXtended Multi-Processing），后来演变成了第8版的生产线，也被称作 XPS（for eXtended Parallel Server）。这个焦点致力于data warehousing和高端平台的并行处理，包括像IBM的RS-6000/SP这样的shared-nothing平台。
1995年
在1995年收购了IIIustra后，第二个焦点集中在object-relational数据库（O-R）技术。Informix在7.x版本的OnLine产品中集成了IIIustra的O-R映射和DataBlades，结果变成了Informix Universal Server（IUS），或者简单地说，就是第9版。
第8版（XPS）和第9版（IUS）都出现在1996年的市场上，令Informix成为第一个内建O-R支持的“big three”数据库公司（另外两个是Oracle和Sybase）。评论家们花了很多心思在DataBlades上，DataBlades后来非常流行，继与IIIustra的合伙后，又有了新架构。这让其他的软件生产商很着急，Oracle在1997年发布了支持时间序列的“嫁接”包，而Sybase让一家第三方公司为其制作了一个没有竞争力的附加产品包。
1997年
在市场上的失败和公司的管理不当，掩盖了Informix技术上的成功。在1997年愚人节那天，Informix宣布他们第一个季度的收入比预期少了10亿美元。公司CEO Phillip White把这些差额怪罪在未能投入足够的精力在核心数据库业务上，而在object-relational技术上投入了太多资源。紧接着，大量的营业损失和裁员相继而来。Informix重审了1994年到1996年的利润，1990年代中期包括给合伙公司的软件许可证其实很大一部分都没有真正售出到终极用户手中，这样不规范的操作致使公司财政产生了超过20亿美元的泡沫。即使在White 1997年7月离开后，公司在1998年又来了一次财务重审。
2001年
从2000年开始，Informix历史上的大事件再也不是集中在技术革新上了。从那一年开始，三月份，Informix购买了Ardent Software，一家自己本来就是收购和合并而来的公司。这次收购为他们那个时候已经很多了的数据库引擎又增加了两个多维引擎UniVerse和UniData（被简称为U2），不仅包括Informix传统的产品，还有Red Brick的面向datawarehouse的SQL引擎、100% Java版本的SQL，Cloudscape（后来被绑定在J2EE的参考安装包内）。
IBM接管
2000年7月，Ardent公司的前任CEO，Peter Gyenes，成为Informix的CEO，并且迅速重整了Informix以让其成为一个更诱人的期待别被别人收购的“猎物”。这样重要的一个决定是要把所有的数据库引擎技术，和应用程序与工具分离开来。
在2001年4月，IBM趁着这次重整，提出了一项来自与沃尔玛（Informix最大的客户）的建议，从Informix购买了数据库技术、品牌、未来开发计划（代码名为“Arrowhead”的内部工程）以及和这些相关的超过10万余计的用户基础。剩下的生产应用程序和工具的公司重新命名为Ascential Software。在2005年5月，IBM买下了Ascential，在IBM的Information Management Software的投资组合下重新聚合了Informix的资产。
Infomix数据库版本发布
经过优化的新版IDS 11.5代号“Cheetah 2”，可支持客户运用IBM大型机系统提供的多种信息管理技巧，增强集群服务器环境的业务表现。因此IDS可谓是业界第一款非大型机级数据服务器，无论地理位置远近或与备份数据中心站点间距离长短，它都能为集群数据中心提供低成本持续数据可用性和灾难恢复能力。
IBM负责数据管理市场推广的副总裁Inhi Cho表示：“目前全球各行各业、各种规模的企业都希望能够与本地及全球企业开展不间断业务交易，获得竞争性优势。而新版IDS卓越的速度、灵活性和高效可帮助我们的客户企业在自我发展的过程中，不断增强整体业务表现并降低相关成本。”
新版IDS 11.5在原版基础上进行了多处改良，其领先的稳定性和交易性能得到了进一步的提升，可更好地支持用户减少所需的服务器的数量和成本。它允许客户以更少的硬件服务器管理相同数量的数据，因此大大降低了客户对软件许可、管理成本、能源和空间的需求。
依此类推，当企业内部拥有数百或数千台应用或系统时，IDS 11.5可为分布广泛的数据管理节约大量资源、空间和成本。那些依赖不间断信息访问、且缺乏管理众多数据库专业IT员工的小型企业和机构也能从多功能IDS 11.5中受益。
英国Trafficmaster（一家领先的智能驾驶服务提供商）的一名项目经理Jon Tasker表示：“我们选择使用Informix将大型数据仓库整合在一起，为我们的客户提供更智能的卫星导航服务和更短的驱车路程。我们需要全天候管理350万条路段上多达10万辆汽车的行驶速度相关数据，这是一项巨大的数据管理挑战，而且这些数据还在持续不断的增加。在我们的基准测试流程中，Informix凭借其优异的性能、可扩展性和稳定性从众多领先解决方案中脱颖而出。”
Jenzabar公司负责软件与服务的副总裁Ben Bassett表示：“Jenzabar对IBM IDS 11.5中的几项新功能印象深刻。改进的高可用性支持我们这些高等教育市场的客户更轻松地为委托人提供全天候不间断的服务。此外，我们对IBM在IDS产品线中所展示的承诺感到尤为欣喜。这一系列版本的推出不仅增加了IDS的实际价值，反过来还提升了我们对该产品线，以及我们与IBM之间合作关系的满意度。”
作为IBM信息管理软件组合中的一项战略要素，IDS 11.5数据服务器可提供出色的快速在线交易处理（OLTP）性能，高可靠性和低成本管理能力。因此，IDS也一举成为了众多细分市场上领先的集成数据服务器，这些市场包括零售、电信、政府/公共领域、旅游和娱乐等。IIDS持续受到众多客户的垂青和欢迎，越来越多的企业在本企业中选择使用IDS。例如，仅北美地区前十大美国零售商中就有八家将其用于重要业务应用；全球有95%的电信公司均采用IDS支持本企业的数据管理。
Infomix数据库基本概念
1. Page Size
页面大小，由系统决定，用户无权更改。
2. Mirror { MIRROR }
是否作镜像处理。
3. Tape Dev. { TAPEDEV}
数据备份所用的磁带设备，需要选择好或提前准备好，如使用硬盘文件的话，创建方法同准备硬盘空间。
主要参数有磁带设备路径(可以是硬盘的某个文件，或/dev/null )、磁带块大小(Block Size)及总容量(Total Tape Size)。
4. Log Tape Dev. {LTAPEDEV}
数据库逻辑日志备份使用的磁带设备。
5. Stage Blob {STAGEBLOB}
INFORMIX-OnLine/Optical为存储目的地是光盘的blobs所用的blobspace名称。仅当你使用光盘 和INFOMRIX-OnLine/Optical时，才有可能使用此参数。
6.Root Name {ROOTNAME}
存储OnLine配置的根数据库空间（dbspace），在所有数据库空间中名字唯一。默认是rootdbs,建议沿用此名称。
Primary Path： { ROOTPATH }
rootdbs的路径，须预先准备好。
Root Size： { ROOTSIZE }
规定rootdbs的大小。建议不要小于50MB。
Root Offset ： {ROOTOFFSET }
Root Name 设备的偏移量。对于Primary Path指定的设备是操作系统文件时，必须是0；如果Primary Path是原始设备（硬盘、或可擦写光盘等）可以指定起始位置。
8. Mirror Path { MIRRORPATH }
如果Mirror处选择了Y，此处要求输入镜像设备或文件的绝对路径。
Mirror Offset：{ MIRROROFFSET }
镜像设备的偏移量。对于Mirror Path指定的设备是操作系统文件时，必须是0；如果Mirror Path是原始设备（硬盘、或可擦写光盘等）可以指定起始位置。
9. Phy. Log Size { PHYSFILE }
规定物理日志大小（大于等于200K）。初始化后仍可以调整。
10. Log. Log Size { LOGSIZE }
规定逻辑日志大小。初始化后不可改变。
最小值=200
最大值=（rootsize-physfile-512-(63*((pagesize)/1024))/logfiles
Number of Logical Logs { LOGFILES }
规定逻辑日志的个数。初始化后可以增加。
11. Logical Log：
记录数据库每个操作的日志，主要是为了在数据库崩溃后最大限度的恢复毁坏的数 据。Informix OnLine最少有六个逻辑日志，记录依次循环存放。要定期对其进行备份，备份后的日志仍可使用。在当全部日志写满而仍未进行备份时，OnLine将停止运转，直到有可用的逻辑日志。将数据库设为No Log 模式、或逻辑日志备份设备是/dev/null时除外。
12.Server Number { SERVERNUM }
数据库服务器编号（0～255）。规定了共享内存存储中的相对位置，选择的数值并不重要。只是要求本地主机上的每个OnLine数据库服务器选择的值都要唯一。该值在网络上不一定是唯一的，因为0值是默认设置。建议你选择一个非0值以避免重复。
13. Server Name { DBSERVERNAME }
规定与这个OnLine的特定出现相联系的唯一名字。与环境变量INFORMIXSERVER的值相同。与sqlhosts文件中的一个通讯协议相联系。
14. Server Aliases { DBSERVERALIASES }
数据库别名。
15. Max # of Logical Logs { LOGSMAX }
逻辑日志的最大个数。主要是为在共享内存中为逻辑日志预留空间。
16. Max # of Locks { LOCKS }
最大的锁数。数据库操作中同时使用的各类锁的总数的上限。
17. Max # of Buffers { BUFFERS }
最大缓冲区个数。
Infomix数据库常用命令
oninit命令 语法 oninit [-s] [-i] [-p] [-y]
oninit 将系统从off-line模式变为on-line模式
oninit -s 将系统从off-line模式变为quiescent模式
oninit -i 初始化系统
oninit -p 在共享内存初始化时，不搜索，删除临时表
oninit -y 对提示自动回答yes
oninit -v 加入这个选项显示oninit处理过程
oninit-- 键入此命令可以获得使用帮助
oninit命令用来改变系统的运行模式。其中-i选项用于初始化系统的root dbspace。注意，root-dbspace一旦被初始化，则等于整个数据库系统被初始化。
如果用户希望在计算机启动时自动自动启动动态服务器系统，请在系统初启文件（在许多UNIX系统中为/etc/rc）中加入oninit命令（不加任何选项）。
onmode 命令
语法： onmode [-k] [-m] [-s] [-u] [-y]
onmode -k 执行立即shutdown，将系统变为off-line模式
onmode -m 将系统从quiescent模式变为on-line模式
onmode -s 执行graceful shutdown
onmode -u 执行immediate shutdwon
onmode -y 对提示自动回答yes
onmode 命令同样用于改变动态服务器的运行模式。除了上述选项外,onmode还有很多与改变系统运行模式无关的选项。
利用onspaces命令创建数据空间
语法： onspaces -c [-b] [-d] [-z] [-m] [-o] [-p] [-s] [-t]
-c 创建blobspace或dbspace
-b blobspace blobspace名
-d dbspace dbspace名
-g page size blobpages大小
-m mirror 镜像设备设的全路径名和偏移量（KB)
-o offset 偏移量（KB)
-p pathname chunk设备的全路径名
-s size dbspace大小（KB)
-t 创建临时dbspace
onspaces命令用于创建数据空间、临时空间和存储blob数据的空间（blobspace)。键入onspaces--可以获得该命令的联机帮助。利用onstat -D或onstat -d可以看到系统中的关于数据空间的重要信息。包括：chunk的状态、空闲、每一chunk读写的次数。系统中可能包括的多个系统空间，特别当进行数据分片后，我们建议用户最好能利用命令行来创建数据空间。
可以利用如下命令创建数据空间：
onspaces -c -d datadbs1 -o 0 -p /dev/rrvol3 -s 60000
可以用如下的方式创建临时数据空间：
onspaces -c -d tempdbs1 -t -o 0 -p /dev/rrvol5 -s 80000
在系统中，临时数据空间非常重要，通常情况下，应将多个临时数据空间分布在独立的物理设备上。
利用onspaces命令删除数据空间
增加或删除chunks
语法： onspaces -a -d [-m] [-o] [-p]
-a spacename 为dbspace新增chunk
-m pathname 镜像设备的全路径名和偏移量（KB）
-o offset 主设备的偏移量（KB)
-p pathname chunk设备的全路径名
-s size chunk大小
-d spacename 删除chunk
-o offset chunk设备的偏移量（KB)
onspaces不仅能创建数据空间还能删除数据空间、临时数据空间或存储blob数据的空间。在删除数据空间时，必须首先保证它是无用的，即该数据空间上无数据库或表。
如需删除数据空间，请键入如下命令：onspaces -d dbspace_name /blobspace_name
数据空间最初由一个chunk（first chunk）构成，一旦其空间用尽，用户必须追加chunk为了提高系统性能，用户在为数据空间分配chunk时需要计算以保证它的大小能适应未来的需要，否则在追加chunk的时候，它与先前的chunk在物理上不一定相邻，导致增加读取数据的时间。关于如何计算空间需求将在以后章节中阐述。利用onspaces命令可以对数据空间增加或者删除chunk,除此之外，利用该命令还可以完成如下任务：启动镜像、中止镜像或改变chunk的状态。
例如可以用如下命令为数据空间增加chunk：
onspaces -a -d datadbs1 -0 60002 -p /dev/rrvol3 -s 60000
再如可以用如下方式从数据空间中删除chunk：
onspaces -d datadbs1 -o 60002 -p /dev/rrvol3 -s 60000
onparams 命令语法：onparams -a -d -p [-d] [-s] [-l]
-a 新增逻辑日志
-d dbspace 指定日志存放的dbspace
-s size 新增逻辑日志的大小（KB）
-d 删除逻辑日志
-l logid 指定删除一个逻辑日志
-p 改变物理日志
-d dbspace 新物理日志存放的dbspace名
-s size 物理日志大小（KB)
系统在初始化时自动地在root dbspace中创建逻辑日志和物理日志。在DBMS系统中，尤其在OLTP环境下，数据库的操作非常频繁，日志中必须记录大量的信息，所以用户最好能将多个日志文件分布在不同的设备上。有一种非常简单的方法： 即按所需大小创建逻辑日志，同时创建一个较小的物理日志，系统初始化完毕后，再将物理日志移至其它设备。关于如何确定所需的物理日志的大小，将在以后的章节详述。 利用onstat -l命令可以看出系统中所有新增的逻辑日志被标识为A。这些逻辑日志只有在系统进行归档后才会真正被使用。为了激活这些逻辑日志有一种简单的方法：执行一次“伪”归档。具体步骤如下：将参数TAPEDEV设置为/dev/null然后运行一次ontape -s。也可以执行onbar -F命令。由于伪归档并不真正归档系统信息，所以千万要适时地对系统进行真正的归档操作。
只有在逻辑日志真正无用时才能将其删除。利用onstat -l 可以看出所有的空闲日志被标记为F。如果逻辑日志中包含事务回滚或快速恢复所需的信息，该逻辑日志是不能被删除的。利用onstat -l命令可以看出接受当前事务的日志被标记为C。如果逻辑日志包括最后一个检查点记录，它也是不能被删除的，只有当检查点记录被写入下一个日志忠并且上一个日志被备份后，该日志才能被删除。利用onstat -l命令可以看出包含最后一个检查点记录的日志被标记为L。用户可以利用onmode -c命令强制写检查点记录直至最后一个检查点记录被写入所要求的日志为止。
