INFORMIX _生活百科

文章插图
INFORMIX【INFORMIX】Informix是IBM公司出品的关係资料库管理系统（RDBMS）家族。作为一个集成解决方案，它被定位为作为IBM线上事务处理（OLTP）旗舰级数据服务系统。IBM对Informix和DB2都有长远的规划，两个资料库产品互相吸取对方的技术优势。在2005年早些时候，IBM推出了Informix Dynamic Server（IDS）第10版。目前最新版本的是IDS11（v11.50，代码名为“Cheetah 2”），在2008年5月6日全球同步上市，
基本介绍中文名：INFORMIX
出品：IBM公司
性质：关係资料库管理系统
类型：集成解决方案
发展历程1980在一家早期的S-100/CP/M公司Cromemco工作的Roger Sippl和Laura King开发了一个基于ISAM技术的小型的关係资料库，作为一个报表记录器软体的一部分。1980年，Sippl和King离开Cromemco去开发关係资料库系统（RDS）。他们的第一个产品叫做马拉松（Marathon），本质上是一个他们以前那个ISAM作品的16位版本，并且在Onyx作业系统上发布，这种Onyx作业系统是一个为早期的ZiLOG微处理器开发的Unix作业系统。

文章插图
INFORMIX在开发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的协作下，Informix发布了具备动态可扩展结构（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的资产。版本发布经过最佳化的新版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支持本企业的数据管理。基本概念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))/logfilesNumber 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 }最大缓冲区个数。常用命令oninit命令语法 oninit [-s] [-i] [-p] [-y] oninit　将系统从off-line模式变为on-line模式oninit -s将系统从off-line模式变为quiescent模式oninit -i初始化系统 oninit -p在共享记忆体初始化时，不搜寻，删除临时表oninit -y对提示自动回答yesoninit -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 shutdownonmode -u执行immediate shutdwononmode -y对提示自动回答yesonmode 命令同样用于改变动态伺服器的运行模式。除了上述选项外,onmode还有很多与改变系统运行模式无关的选项。利用onspaces命令创建数据空间语法： onspaces -c [-b] [-d] [-z] [-m] [-o] [-p] [-s] [-t]-c 创建blobspace或dbspace-b blobspace blobspace名-d dbspacedbspace名-g page sizeblobpages大小-m mirror镜像设备设的全路径名和偏移量（KB)-o offset偏移量（KB)-p pathnamechunk设备的全路径名-s size　dbspace大小（KB)-t创建临时dbspaceonspaces命令用于创建数据空间、临时空间和存储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 pathnamechunk设备的全路径名-s size　chunk大小-d spacename删除chunk-o offsetchunk设备的偏移量（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 60000onparams 命令语法：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命令强制写检查点记录直至最后一个检查点记录被写入所要求的日誌为止。