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命令強制寫檢查點記錄直至最后一個檢查點記錄被寫入所要求的日志為止。